[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal: Domain for Japanese ruby markup ala HTML5
Please remember that my focus is on everything that is *not* technical documentation, and expressly includes textbooks as a primary use case. So saying that tech docs do not need ruby is useful data but not a compelling argument against the need for it: DITA is *not* just for technical documentation and we need to remember that when considering new features. Is there any *technical* objection to the ruby design as I've presented it? I would not expect one since I copied the HTML5 design without modification. When I went to create some sample Japanese DITA documents for my visit to Japan for the 2010 DITA Festa, I found some Japanese poetry from the Japanese equivalent of Project Gutenberg. That poetry, marked up in HTML, used ruby extensively. Those sorts of documents are exactly the type of document I focus on: non-technical documents. It would have been impossible for me to create those samples and render them correctly without first adding ruby markup to my DITA vocabulary, which I did. So from my standpoint, my current and potential users of DITA could not use it without ruby markup if they are creating Japanese-language documents. Given that ruby has been in HTML for decades it seems rather odd in fact that DITA has not had equivalent markup to date. Cheers, E. On 2/3/12 10:01 AM, "JoAnn Hackos" <joann.hackos@comtech-serv.com> wrote: > Hi, > I thinking Eliot, you may be stretching the circumstances and overstating > the case. Technical communications documents have been happily produced > from DITA into Japanese for years with no need for Ruby. Ruby is not > essential for Japanese documents at least with PDF etc. publications. > > My understanding from Translation SC discussions before 1.2 is that Ruby > is chiefly used in schoolbooks. Now we have the note from Tetsuya Sekine > that mentions several important issues, possibly connected with ebooks. > > I've copied his note here for those who did not see it. > > I think it's really important that we not overstate or misrepresent the > case. > > I invite all members of the DITA Translation Subcommittee to comment in > this thread. > > > Thanks, JoAnn > > JoAnn T. Hackos, PhD > President > Comtech Services Inc. > 710 Kipling Street, Suite 400 > Denver, CO 80215 > Joann.hackos@comtech-serv.com > 303-232-7586 > > Hi all, > > I was already discussed some of you, regarding Ruby functionality. > Only problem is that meeting is held during the time, I am not usually be > able to attend. > > I discussed this issue with some colleagues in the field. > > 1.Currently, most of the users and information developers are not > necessary needing Ruby. > WHY: Because in Technical Communication, this does not have much impact on > current targeted audiences (Paper, PDF, Online Help) > HOWEVER: From the point of accessibility and computer-voiced instructions > feature especialy to the new deliverables such as smartphone, Ruby will be > needed. > > 2.Rendition part is already supported by tools like AH XSL Formatter, and > the same things applied with current HTML browser and its standard > (HTML5/CSS3). > 3.DITA adaption for the commercial publishing definitely needs Ruby, so > this can contribute DITA to be adapted more in that field, in conjunction > with ePub. > 4.It is not a good way to extend Ruby as the Japanese own specialized > implementation because this action is against open standard. > (From my own experiences, Japanese have a tendency to come up with own > domestic standard and make things complicated, not align with the standard) > > PS > In addition to Ruby, we want to have the similar elements as used in > <indexterm>/<index-sort-as> for glossary entries, in order to sort from > "yomigana" > One of our customers decided to specialize in order to have sorting in > glossary > > As said enough, > I am for the Eliot, Nancy's proposal for standardization in DITA data > model, align with HTML5 and ePub etc. > > Tetsuya Sekine > > ====================================================================== > Tetsuya Sekine > President, Principal Consultant > InfoParse, Inc. > <your one stop DITA contact/> > <DITA + /> > *email: ecmp@infoparse.com | Skype <callto://tetsekine> > *url: www.infoparse.com | phone: 81 3-3736-8180 > > > > > > > > On 2/2/12 3:42 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote: > >> The rational as I provided it to the TC during meeting was: >> >> 1. Ruby markup is essential for the publication of Japanese-language >> documents (and for some other ideographic languages). >> >> 2. Japan is rapidly adopting DITA >> >> 3. Many DITA users localize their documents to Japanese >> >> 4. Without a ruby solution, Japanese users either cannot use DITA or will >> be >> forced to invent their own individual specializations. >> >> Nancy Harrison echoed the fact that ruby markup is essential for Japanese >> documents. >> >> 5. The ruby markup is well-defined in HTML and needs no refinement from >> us. >> Therefore, the standardization cost to the TC is very low (and in fact >> I've >> already done everything except write the language reference topics since I >> originally implemented this in DITA for Publishers). >> >> 6. The rendition implementation is trivial for HTML outputs and available >> for PDF outputs (i.e., Antenna House have developed particular XSL-FO >> patterns for rendering ruby annotations). >> >> Note that in my proposal the ruby markup is packaged as a separate domain >> and would presumably not be integrated into the generic document type >> shells >> provided by the TC and so would not add to the set of elements seen by >> default for typical DITA users using default document types. >> >> Cheers, >> >> E. >> >> On 2/2/12 4:33 PM, "JoAnn Hackos" <joann.hackos@comtech-serv.com> wrote: >> >>> Hi, >>> Eliot, could you put together a rationale for adding Ruby support that >>> we >>> can present to the Translation SC? I have your original email to the >>> DITA >>> TC but what I need is why this is valuable for the entire DITA >>> community. >>> The SC didn't think that was true when we were reviewing DITA 1.2 >>> proposals. >>> >>> Thanks, >>> JoAnn >>> >>> JoAnn T. Hackos, PhD >>> President >>> Comtech Services Inc. >>> 710 Kipling Street, Suite 400 >>> Denver, CO 80215 >>> Joann.hackos@comtech-serv.com >>> 303-232-7586 >>> >>> >>> >>> >>> >>> >>> >>> On 2/1/12 3:06 PM, "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote: >>> >>>> Hi, >>>> >>>> It would be indeed interesting to pass the new proposal to the >>>> Translation >>>> SC for analysis. >>>> >>>> Is there anything really different in the new proposal for adding Ruby >>>> support? What has changed that could make the Translation SC change its >>>> opinion? >>>> >>>> Regards, >>>> Rodolfo >>>> -- >>>> Rodolfo M. Raya rmraya@maxprograms.com >>>> Maxprograms http://www.maxprograms.com >>>> >>>> >>>>> -----Original Message----- >>>>> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On >>>> Behalf >>>>> Of JoAnn Hackos >>>>> Sent: Tuesday, January 31, 2012 10:14 PM >>>>> To: Eliot Kimber; Richard Hamilton >>>>> Cc: DITA TC >>>>> Subject: Re: [dita] Proposal: Domain for Japanese ruby markup ala >>>>> HTML5 >>>>> >>>>> I think this proposal needs to be discussed by the Translation SC. >>>>> Let's >>>> see if >>>>> we can reconvene it. We considered Ruby markup for DITA 1.2 and >>>>> decided >>>>> against recommending it. I don't know if the members of the SC think >>>>> differently today. >>>>> >>>>> JoAnn >>>>> >>>>> JoAnn T. Hackos, PhD >>>>> President >>>>> Comtech Services Inc. >>>>> 710 Kipling Street, Suite 400 >>>>> Denver, CO 80215 >>>>> Joann.hackos@comtech-serv.com >>>>> 303-232-7586 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 1/25/12 10:21 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote: >>>>> >>>>>> Good point--the markup is primarily driven by Japanese requirements >>>>>> but >>>>>> it is not unique to Japanese typography as you say. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> E. >>>>>> >>>>>> On 1/25/12 11:18 PM, "Richard Hamilton" <hamilton@xmlpress.net> >>>>>> wrote: >>>>>> >>>>>>> Eliot, >>>>>>> >>>>>>> I agree that it probably should be a domain, for the reasons you >>>>>>> describe. >>>>>>> However, there are other languages where a phonetic "ruby" could be >>>>>>> useful. >>>>>>> I've seen the same kind of thing in Chinese texts (mostly in >>>>>>> language >>>>>>> learning aids), and I'm sure there are other uses. >>>>>>> >>>>>>> So, I would suggest that any specification description not imply >>>>>>> that >>>>>>> usage is limited to Japanese. >>>>>>> >>>>>>> Best Regards, >>>>>>> Richard >>>>>>> ------- >>>>>>> XML Press >>>>>>> New from XML Press: >>>>>>> WIKI: Grow Your Own for Fun and Profit >>>>>>> http://xmlpress.net/publications/wiki-how-to-grow >>>>>>> >>>>>>> On Jan 25, 2012, at 8:56 PM, Eliot Kimber wrote: >>>>>>> >>>>>>>> HTML5 provides an improved version of HTML 4's <ruby> markup, which >>>>>>>> is required for Japanese-language documents that include kanji >>>>>>>> (ideographic) >>>>>>>> characters. >>>>>>>> >>>>>>>> In Japanese, the pronunciation of ideographic characters cannot >>>>>>>> always (or >>>>>>>> often) be known from context. The ideographic characters are >>>>>>>> annotated with their phonetic transliteration, a "ruby", which is >>>>>>>> rendered above or beside or following the ideographs. This is >>>>>>>> standard Japanese typography. >>>>>>>> >>>>>>>> In the context of the DITA for Publishers vocabulary I have defined >>>>>>>> a direct copy of the HTML5 markup design, e.g.: >>>>>>>> >>>>>>>> <p> 探険船シビリアコフ号の北氷洋航海中に撮影されたエピソ >>>>> ード映画の中に、一頭 >>>>>>>> の<ruby> >>>>>>>> <rb>白熊</rb> >>>>>>>> <rp>（</rp> >>>>>>>> <rt>しろくま</rt> >>>>>>>> <rp>）</rp> >>>>>>>> </ruby>を射殺し、その子を生け捕る光景が記録されている。 >>>>> </p> >>>>>>>> >>>>>>>> Implementing this for HTML output is trivial--just copy to output. >>>>>>>> For PDF it's a little more work but can be done in XSL-FO. >>>>>>>> >>>>>>>> <ruby> and its ruby-specific subelements are specializations of >>>>> <ph>. >>>>>>>> >>>>>>>> I am proposing this as a new domain simply to keep the vocabulary >>>>>>>> isolated so that non-Japanese-language documents need not include >>>>>>>> this markup. >>>>>>>> But it >>>>>>>> would equally appropriate to add it to the DITA base vocabulary as >>>>>>>> well. >>>>>>>> >>>>>>>> The Ruby markup works as expected in most modern browsers and in at >>>>>>>> least iBooks for EPUB. I have not tested on Kindle Fire. >>>>>>>> >>>>>>>> The HTML5 specification for <ruby> is here: >>>>>>>> >>>>>>>> http://dev.w3.org/html5/spec/Overview.html#the-ruby-element >>>>>>>> >>>>>>>> The D4P vocabulary module and HTML implementation for the Open >>>>>>>> Toolkit is available as part of the DITA for Publishers package, >>>>>>>> dita4publishers.sourceforge.net. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Eliot >>>>>>>> >>>>>>>> -- >>>>>>>> Eliot Kimber >>>>>>>> Senior Solutions Architect >>>>>>>> "Bringing Strategy, Content, and Technology Together" >>>>>>>> Main: 512.554.9368 >>>>>>>> www.reallysi.com >>>>>>>> www.rsuitecms.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -------------------------------------------------------------------- >>>>>>>> - To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>>>>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Eliot Kimber >>>>>> Senior Solutions Architect >>>>>> "Bringing Strategy, Content, and Technology Together" >>>>>> Main: 512.554.9368 >>>>>> www.reallysi.com >>>>>> www.rsuitecms.com >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org >>>> For additional commands, e-mail: dita-help@lists.oasis-open.org >>>> >>> >> >> -- >> Eliot Kimber >> Senior Solutions Architect >> "Bringing Strategy, Content, and Technology Together" >> Main: 512.554.9368 >> www.reallysi.com >> www.rsuitecms.com >> > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]