[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
Yes, of course. Let's see how other members of the Translation SC weigh in. Tetsuya appears to agree with your argument. 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/3/12 9:09 AM, "Eliot Kimber" <ekimber@reallysi.com> 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]