Hi Takashi, On Saturday, 2007-08-18 01:05:18 +0900, Takashi Nakamoto wrote:
> > 1) Store that in rtl::OUString. > > 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. I'd consider implementing ruby at OUString an abuse of OUString.. besides that it would be a completely incompatible change, it would increase the size of an OUString instance, which in 99% use cases is just waste. > > 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. Memory consumption. Adding yet another member variable to ScStringCell that again is only needed in not even 1% of use cases is waste. > > 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. Additionally, there's much overhead involved with an ScEditCell and its EditEngine. Calculating with strings obtained from ScEditCell is definitely slower than ScStringCell. > > 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. If ruby was implemented at EditEngine we would end up with just 3: ScStringCell, ScRubyStringCell, ScEditCell. > Switching routine that choose one class from the four > classes for creating an instance of a cell would be complex. I don't think so. You need to distinguish anyway, and subclassing may actually ease things because switching can be done internally using factory patterns and RTTI. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to this [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks.
pgpsic2rSj3Q1.pgp
Description: PGP signature
