[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
I would urge every member of the Subcommittee to comment on this proposal for Ruby. We need your experienced input.
Thank you,
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
From: Don Day <donday@learningbywrote.com>
Date: Fri, 3 Feb 2012 10:32:11 -0600 To: JoAnn Hackos <joann.hackos@comtech-serv.com> Cc: Eliot Kimber <ekimber@reallysi.com>, Rodolfo Raya <rmraya@maxprograms.com>, DITA TC <dita@lists.oasis-open.org>, "dita-translation@lists.oasis-open.org" <dita-translation@lists.oasis-open.org> Subject: Re: [dita] Proposal: Domain for Japanese ruby markup ala HTML5 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. "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 | 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] OnBehalfOf 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'ssee ifwe 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.comwww.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.comwww.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.comwww.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]