ms> DEBUG: GR_Graphics::remapGlyph( 0x00B7 ) -> 0x00B0 tick: 1 [137396920]
ms> DEBUG: fb_LineBreaker.cpp(161) tab run: type=1 height=1358 width=1321 offset
The first one is a normal "info" message from remapGlyphs() and can
generally be ignored. I don't know anything about the second.
ms> appeared about at frequently as the bullets in the document. The
ms> postscript has no bullets but lots of glyphs like circles where my
ms> bullets should be. A quick check of the insert symbol dialog
ms> showed these circles do have ASCII code hex B0 and that a Bullet
ms> in Standard Symbols font has ascii code hex B7
ms> So remapGlyphs ate my bullets upon printing. Can this be fixed soon?
You are seeing the designed behavior. The small circle thing (0xB0)
is the default glyph used when (a) there is no glyph for the thing you
want, and (b) there is no explicit substitution called out in the
RemapGlyphsTable.
So, for whatever reason, the PS printer driver code thinks there is a
zero-width character in that place in that font, and remapGlyph() does
The Right Thing given that pre-condition. If the PS printer character
width stuff were correct and remapGlyphs() didn't do anything, you
wouldn't get a glyph at all in that position. Since there really is a
glyph there, and since PS-to-file produces a large mound of goop that
looks like the definition of the StandardSymbol font, the PS printer
driver code in Abi must be making a mistake.
I'll try to have a look at that PS driver code tonight. It is
probably not a remapGlpyhs() problem per se, but hopefully will be a
trivial problem in the PS driver.
--
[EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
