Hi,

Someone kindly referred to two bugzilla entries related to
the use of ruby-character in Japanese (and possibly others(.

Bug 49073 - FILEOPEN: Furigana (ruby text) and characters with them are missing in opened .docx files.


Bug 44784 - FORMATTING: Japanese Ruby Characters require an offset control in Asian Phonetic Guide

I am creating this maser bug entry regarding Ruby character handling for
bringing some hints from external sources.

At Documentation Foundation mail archive, there has been a (Japanese)
discussion thread about the functional deficiency of using Ruby
characters in OO and LO from the viewpoint of compatibility with MS
Word (.docx) and .odt format.

http://nabble.documentfoundation.org/MS-Word-td3303042.html#a3987515

It started on Sept 12, 2011 and has been running on and off.

In it, the broken compatibility of reading
Japanese documents with ruby characters was raised initially
and discussed.

Someone aka "NON" did a comprehensive study using a simple data and
LibreOffice 3.4.3 / Word 2010 under Windows 7.  (And he/she later
followed that LO 354 didn't change the behavior.)

OBSERVATION:

When Original Japanese data is created using LO343:

 - doc(Word 97/2000/2003) format
   Word can read the file, the display of ruby characters is OK.
   LO   can read the file, the display of ruby characters is OK.

 - docx (Office Open XML output) format
   Word can NOT read the file :-(
   LO   can     read the file, but ruby characters are gone! :-(

   So LO essentially loses the ruby content even if only LO is used
   if the poor user chooses docx format! :-(

 - docx(Word 2007/2010 XML output format
   Word can NOT read the file :-(
   LO   can     read the file, but ruby characters are gone! :-(

 - xml(Office 2003 XML) format
   Word can read the file, but ruby characters are gone! :-(
   LO   ditto.

  Strange/Worse: even in the case when file could be read, the font
  size changed from 10.5 to 12 for no obvious reason, and ruby
  characters became relatively smaller. (I also noticed this earlier.)

When the original data was created by Word 2010:

 - docx format
   LO can read the file, but ruby characters are gone! :-(
   Word can read the file and the display of ruby characters is OK.

 - doc format
   LO can read the file, and the display of ruby characters is OK.
   Word can read the file and the display of ruby characters is OK.

 - xml(Word 2003 XML) format
   LO can read the file, but ruby characters are gone! :-(
   Word can read the file and the display of ruby characters is OK.

 - xml(Word XML)
   LO can't read the file (Generic I/O error!) :-(
   Word can read the file and the display of ruby characters is OK.

 - odt format
   LO can read the file and display of ruby character is OK.
   Word can read the file and display of ruby character is OK.

His/her comment was that analysis routine of XML used by Word seems to
have a problem, and conventional DOC format handling of LO is OK, and
ODT produced by Word is OK also.

BUT, I hope everybody agrees that we have a serious usability problem 
in a heterogeneous environment where people pass document files
around.
(I raised the issue that this problem is a deal killer for OO and LO
in educational market in Japan.)

For those wishing to fix the problem and 
are afraid to do so because they are  unfamiliar with Japanese layout,
W3C's guide titled "Requirements for Japanese Text Layout"
is a treasure trove for those who
attempt proper Japanese layout in print, on screen, etc., and is 
mentioned
in https://bugs.freedesktop.org/show_bug.cgi?id=44784#c6

PS: I was bitten by this bug a few years ago 
when OO didn't pay attention to the following:
MS Word uses a different characters to de-limit ruby characters
from the main text characters under different LOCALE.
(I raised in the now-defunct OO bugzilla etc.)
This was also discussed in the Documentation Foundation mailing list for
Japanese, and someone pointed out the following fix
is in libreoffice core now.

http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=b0539229b1a31925d28a13f9bbda6fd672729bd6

It seemed it was not put into the later OO core due to the
shuffle of hosting sites, etc. :-(
If the patch had been put into the mainline at earlier date, the
current problem may have surfaced earlier and thus had a chance of
being fixed earlier :-(