[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
One additional datapoint- Techcomm deliverables already include epub and mobile html. I don't know if Japanese translations in these formats would require this DITA change or not (afaik we haven't translated that material yet). Sandra On Feb 3, 2012, at 11:09 AM, Eliot Kimber wrote: > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: dita-help@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]