Hello, Kohei, > > I'd say first point is to implement/enable Ruby support in the Calc core :-) > > And the first question may be - where should that extra ruby (phonetic > guide) string be stored? A couple of possibilities:
This is very annoying question. We have to choose one idea from possible ideas, but we have not determined where we will make the phonetic string stored in each cell. Each idea may have its good points and bad points. If you have any recommendation, don't hesitate to tell us. I think this topic should be discussed with related developers including OOo Spreadsheet team. > 1) Store that in rtl::OUString. Excel seems to embed the ruby data into > strings, so this may ease the import/export from/to the Excel file > format. However, doing so will probably require refactoring of the ruby > handling code in Writer and/or raise an eyebrow of the framework > people. ;-) At the beginning of our project, this idea was the first choise, but now we think this implmentation might be very difficult and seek for better ideas. That is because, if we changed OUString, many unexpected errors might be raised. OUString is used commonly and widely in OOo source codes. And, of course, refactoring code in Writer project would be required. I don't want to do it :( > 2) Store that in ScStringCell. This may be easier but string cells are > used a lot, and most likely only a faction of them use phonetic guides > under normal use cases. So, adding another data member to ScStringCell > may not be desirable. Now "Storing phonetic text in ScStringCell" is the first choise because it seems to be easier. I can understand your concerns but I wonder what concrete problems would be raised by this approach? I can't evaluate the bad effect of this idea correctly. > 3) Store that as a cell attribute. If I understand correctly, Writer > uses this approach. Related to this idea, I think storing phonetic text as one attribute of EditTextObject in ScEditCell is also a good idea. ScEditCell seems to be used to store decorated text in a cell. So we can deal with phonetix text as one attribute of a decoration attributes. It doesn't have any bad effect on ScStringCell. EditTextObject seems to be a common class, so we ought to craete newEditRubyTextObject class if this idea is accepted. However, through this change, most cells that just hold Japanese text would be instances of ScEditCell. This is a waste of memory. Anyway, I've not investigated that we can realize this idea yet. This investigation maytake long time. > 4) Or maybe subclass ScStringCell to create ScRubyStringCell, and use an > instance of that class to store the ruby text information when needed ? > Just a wild idea, but could this work (maybe) ? I think this is not a good idea. It would make String type cell have 4 different classes, ScStringCell, ScRubyStringCell, ScEditCell, ScRubyEditCell. Switching routine that choose one class from the four classes for creating an instance of a cell would be complex. Regards, -- Japanese Native-Language project Good-Day Inc. Takashi Nakamoto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
