Hi Eike & Kohei, > But, logically, it would make sense to store the ruby text together with > the base text, because the ruby text is conceptually a property of the > base text. Putting them together would also eliminate the > synchronization problem because the ruby and the base texts would never > be separate. > > One idea I came across in the past was to embed the ruby text > information at the end of the sal_Unicode array, and borrow some bits > from the refCount variable to flag the presence of ruby text, then > OUString would know to look for it. It could be done transparently to > those existing code that doesn't need to use ruby texts, and the size of > OUString would remain the same because there is no additional data > member required.
I wonder how OUString could find the ruby text even if it knew to look for the ruby text. As you say, we shouldn't accept this idea in order to support ruby text in Calc. However, I think this is an ambitious idea as a new concept of i18n. Any attribute, including ruby text, could be managed by OUString. > > > > 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. > > Eike already answered this correctly. Basically, if you add another > data member to a class, it would increase the size of that class by that > new data member size regardless of whether the data is used or not. The > size increase may be small per object, but if there are thousands of > ScStringCell instances, then the increase may become substantial. And > that increase may not be justified if only a fraction of the cell > instances need to use that data member. > > That said. It may be a workable approach if the memory increase turns > out to be a non-issue under average use cases. (who knows?) But I'd > still favor subclassing it and leave ScStringCell alone. Because this is the best way to reduce the number of changing line, shorten development time and complexity of debugging, I prefer this idea. However, I also understand Eike and Kohei's concern about the waste of memory consumption. Hopefully, I would like to know the quantitative data how much the new data member would consume additional memory. > > > > 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. > > So, overall, introducing a new class named ScRubyStringCell as a child > class of ScStringCell, and making changes to the EditEngine class (in > svx) seems to be the most attractive choice. But I wonder what the > level of difficulty is for this approach. I agree. I guess making changes to the EditEngine is just adding new attribute, though I've not investigated EditEngine class yet. In any cases, synchronizing base text and ruby text would be difficult :( -- Japanese Native-Language project Good-Day Inc. Takashi Nakamoto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
