On Tue, 2006-09-12 at 10:31 +0300, Alan Yaniger wrote:
> Hi Caolan,
>
> Word shows the hexpoxed new name, "Niriam", though the font that is
> displayed is no longer "Miriam", but "Arial". I thought that this might
> be because "Arial" was the previous entry in the font table (font[2]) ,
> but that seems to be false: I tried hexpoking "Arial" to "Brial", and
> the text was still displayed in "Arial". Maybe "Arial" is a fallback font.
>
> When I hexpoxed the file again, and instead of "Miriam", substituted
> "Tahoma", I saw the text in the Tahoma font.
>
> Maybe the following is happening:
>
> Word hardcodes ftcStandardChpCTLStsh to always be "3".
>
> It looks in the table to find the name of font[3].
Yeah, that's what I think is happening, and a natural bug (if that's
what this is, and I strongly suspect it is) to not be noticed by
Microsoft in their product as they would always read and write their
base "pre-styles" fonts in the same order, western, symbol font, CJK
font and CTL font, so not setting the base CTL fontid on export mightn't
be noticed. I think we could (fairly confidently at this stage) have a
if (ftcStandardChpCTLStsh == 0)
ftcStandardChpCTLStsh = 3;
and likely (need to check this as well)
if (ftcStandardChpCJKStsh == 0)
ftcStandardChpCJKStsh = 2;
and if MS fixes this and starts writing the values again (unlikely I
guess as they move to xml) we'll be covered.
Given that there is a problem, it's better for us if that the problem is
a missing write of ftcStandardChpCTLStsh by word than an internal table
of per-language fonts to use for a CTL document. :-)
> If a font with that name exists, Word uses it.
> If a font with that name doesn't exist, Word goes to the next entry in a
> list of fallback fonts, like OOo has in VCL.xcu.
Indeed, yes. This is what I'd expect Word to do, see a totally unknown
fontname then just go for Arial it's default "best-coverage" fonts.
> (BTW, I thought that maybe 3 wasn't the magic number, and Word might
> always uses the last font in the font table, which may be a number other
> than 3. To test this, I changed the Latin font of "Header 1" to be
> "Lucida Sans Unicode", thus adding another font to the table. When I
> imported it into OOo, I found that Miriam was still 3, and Lucida Sans
> Unicode was 4. So it seems that the CTL font is not always the last one.)
Yeah, I'd guess that the order that word happens to implement writing
the fonts happens to be first the "pre-style" fontnames, then the style
ones, and then the hard-formatting ones. Though the order they are
written in (before now) should just have been an implementation issue
which we could ignore.
So, was there already an issue opened for this "doesn't get correct CTL
font on import" bug ? Just really need now to attach the sample
demo .docs generated during this thread to an issuezilla bug which show
that we need a special case to handle the default CTL font when none is
set in the base style. A little patch that does the = 3 change and in a
comment reference that issue (because it'll look a little strange to
anyone in the future) and we're basically done I guess.
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
