> On Fri, 2007-08-17 at 09:34 +0200, Daniel Rentz wrote: > [...] >> >> 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: > > 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. ;-) > -1. rtl::OUString is a general and wide-use class.
> 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. > -1. I agree with you. > 3) Store that as a cell attribute. If I understand correctly, Writer > uses this approach. > 0. This solution seems correct, but "only a faction of them use phonetic guides", so I am not really for this one. > 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) ? +1. It would not pollute any other class and could be transparent enough for other parts of code. > > Any thoughts on this? > Well, there's already in OOo code Python, StarBasic and Java. Now I see Ruby and R. I am starting to think (and hope) that there will be a day when macros won't be limited to StarBasic but could be _natively_ in all those languages. And yes, I know that you can already do that with webservices and -headless mode, but it's not "human user compliant" yet. My 2 cents, Regards, -- Michel Loiseleur --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
