[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
On the subject of more general sorting, we already have a booked proposal of which I am the primary sponsor to define a general "sort-as" facility for DITA 1.3. Cheers, E. On 2/3/12 10:32 AM, "Don Day (LbyW)" <donday@learningbywrote.com> wrote: > Thanks for this note from Tetsuya-san. I read each point of it as being in > agreement that this proposal fits both current needs beyond Tech Pubs and > aligns well with emerging requirements (as noted already by Nancy Harrison and > other publishers to the Japanese market). Even point 4 is not an objection to > the proposal--it is a statement about the problems that would arise in the > lack of a standard recommendation. I appreciate his on-the-ground > observations. > > So the TC should also give consideration to Tetsuya-san's additional request > for help with indexterm/index-sort-as glossary issues, but I believe that is > separate from the inline Ruby itself. I suspect Eliot has something on that, > but I'll ask him to submit it as a separate stage 1 proposal that we can vote > to merge if in fact it becomes part of the same domain. > > > > Don R. Day <mailto:donday@learningbywrote.com> > > DITA and XML Consultant, Learning by Wrote <http://learningbywrote.com/> > Co-Chair, OASIS DITA Technical Committee > <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita> > > > "Where is the wisdom we have lost in knowledge? > > Where is the knowledge we have lost in information?" > > --T.S. Eliot > > > > > On 2/3/2012 10:01 AM, JoAnn Hackos 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 <http://www.infoparse.com> | phone: 81 3-3736-8180 >> >> >> >> >> >> >> >> On 2/2/12 3:42 PM, "Eliot Kimber" <ekimber@reallysi.com> >> <mailto: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> >>> <mailto: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> >>>> <mailto: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> >>>>>> <mailto: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> >>>>>>> <mailto: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 <http://www.reallysi.com> >>>>>>>> www.rsuitecms.com <http://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 <http://www.reallysi.com> >>>>>>> www.rsuitecms.com <http://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 <http://www.reallysi.com> >>> www.rsuitecms.com <http://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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]