Hi Caolan,
I appreciate your guidance here. Yes, in my Word document, the CTL font
is set higher up in the chain. "Header 1" inherits from "Header" which
inherits from "Normal", which is where the CTL font is set. But
curiously, I found that if in Word I change the CTL font in "Normal" to
the Hebrew font "Miriam", a hex dump on the doc file shows one less
0x4a5E "srpm" than if I change it to any other font. And indeed I found
that when importing the file with "Miriam" to OOo, there is one less
call to Read_FontCode. As a result, the variable "bCTLFontChanged" is
"false" when WW8RStyle::Set1StyleDefaults() is called, and OOo sets the
display font to OOo's default CTL font instead of to "Miriam".
Do you know why MS Word is saving the file this way when the font is
"Miriam"? Might "Miriam" be defined in some other setting, and Word
thinks that "Normal" is getting the font from there?
Thanks,
Alan
Caolan McNamara wrote:
On Thu, 2006-09-07 at 17:12 +0200, Alan Yaniger wrote:
Hi Caolan,
Thanks for your help. If I may ask for more help:
I've noticed that when a certain Hebrew font is defined in Word as the
font of the "Header 1" style, Read_FontCode is not called with the
font's id passed as an argument. Instead of displaying the text with the
"Header 1"-defined font , OOo uses the default CTL font. If in Word I
change "Header 1" to use a different Hebrew font, Read_FontCode *is*
called with the font's id passed as an argument, and the text looks fine.
The calls to Read_FontCode apparently are determined by the sprm, as
defined in GetWW2SprmDispatcher()
I would like to debug this by making a copy of the Word document,
changing the Header 1 font in one of them, importing the two files into
OOo, and dumping the sprm's of the two files and their contents, and
then comparing the dumps.
a) Do you think this is the proper way to debug this?
b) If so, how would I create such a dump?
Well, what format is your document in ? Word 97+, Word 6/95 or Word 2.
Probably Word97 (in which case the table used is
"GetWW8SprmDispatcher"), but yes, when the importer sees the "srpm" in
the stream it calls the appropiate handler for that code and for the WW8
fontcode setting for CTL I'd expect the srpm to be 0x4a5E (for WW8)
You speak here of a style. Styles inherit from eachother, so if e.g. a
Heading 1 does not explictly set a font it would inherit the font from
its parent. In MSWord itself you have the styles and formatting menu. If
you investigate there you should be able to see what Word says about
your style. Writer is similiar if you press F11 and right click on
Heading 1 and modify and look at the text in the organizer tab. For
example if it is based on something else (linked with) and what explicit
overrides are applied to this style. Following the chain backwards in
the UI of writer and word should show where the font is really explictly
set.
You need to know where the font that "Heading 1" should be using was
really set. If it was explicitly set in word for Heading 1, but didn't
appear in Writer correctly, or if this actually happened in a parent
style and Heading 1 import itself is fine.
At the top of the style chain you have the "Normal" in word and
"Default" in writer style. The defaults for these styles, because they
are the top of the chain, are a little different. They are read in
ww8scan.cxx into ftcStandardChpCTLStsh from the header of the stylesheet
which is at the start of all the styles.
So, check in writer and word in the UIs where the difference in the
style chain occurs, and start work on that style, or on where the
initial default fontid for CTL is set.
Once you are looking at the right style, then tweaking the srpms by
poking is a reasonable approach. There are some notes here though...
1. in word itself make sure that fastsave is disabled as otherwise the
documents are really really difficult to work with, this is in the
options->save of word somewhere near the end of the menubar
2. word documents are ole structured storage documents so they are
effectively a pile of streams combined into one file, so you will see a
flattened view with a basic hexeditor, but you can still work with it
for a little hex editing.
3. And finally the fileformat is little endian so e.g. 0x4a5E will be
stored as 5E 4A in the stream.
Any hexediter of your choice would be sufficient to find 0x4A5E's and
change the following fontid value, for example here's my primitive
viewer and poker
http://www.skynet.ie/~caolan/Packages/chex.html
http://www.skynet.ie/~caolan/Packages/cpoke.html
C.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
