[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]