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" <> 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
>
> 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: | Skype <callto://tetsekine>
> *url: www.infoparse.com | phone: 81 3-3736-8180
>
>
>
>
>
>
>
> On 2/2/12 3:42 PM, "Eliot Kimber" <> 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" <> 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
>>>
>>> 303-232-7586
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2/1/12 3:06 PM, "Rodolfo M. Raya" <> 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
>>>> Maxprograms http://www.maxprograms.com
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [mailto:] 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
>>>>>
>>>>> 303-232-7586
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 1/25/12 10:21 PM, "Eliot Kimber" <> 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" <>
>>>>>> 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:
>>>>>>>> For additional commands, e-mail:
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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:
>>>>>> For additional commands, e-mail:
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>>>
>>>
>>
>> --
>> 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
