I had upgraded from 1.1.1 (stable) to 1.1.2pre-1 in hopes the
problem would go away, but it hasn't. libpng requres the users
program to set up a read callback, so that it can copy n bytes
from the data stream into a buffer so that libpng can start
decoding these bytes. On libc5 systems, stepping into this function
shows a corrupted stack, where the stack seems to be shifted 8
bytes (on my 32-bit Intel libc5 system) up... all the pointers
have incorrect values in them, and I don't know enough about
Intel assembler to figure out why the compiler is doing this.
In fact, if you re-compile AbiWord to reference the pointer
that is 2 more down the argument list (32-bit pointers are
4 bytes, times 2 = 8 bytes total), everything works great
because that's where the real pointers should be.
I have this problem with everything that uses libpng (gimp,
AbiWord, etc.).
> I unpacked the fonts to /usr/share/psfonts/abi and put fonts.dir there
> as well. AbiWord would not load with anything else, like my standard
> /etc/X11/fonts/Type1 directory, as the font directory, even though I
> made all the requisite afm/pfa files and updated fonts.dir. I am using a
> short shell script to start AbiWord with setting the fontpath.
Hm... that may be related to that known bug, which I hope to fix today,
which is that AbiWord does not consider tabs alone to be whitespace in
seperating the fields of the fonts.dir (it only knows spaces).
> So by sheer trial and error I was able to coax AbiWord to use Cyrillic
> characters. It works now.
I wonder if the trial and error corresponded to some pretty
strict (and somewhat inconvenient) requirements of AbiWord to
need 4 instances of each font (regular-i, regular-r, bold-i, bold-r)
to work properly.
> I can't figure out why none of the other Type 1 fonts I have on my
> system seem to work with AbiWord so far. What does AbiWord do with font
> names and what is font (nil)?
This message actually isn't as bad as it seems, in most cases.
The message is from the hash accessor in the font table. When it
says it found (nil) in the hash, it just didn't find the requested
font, and it's the caller's responsibility (in this case, the X
graphics class which was itself requested to start using a specific
font) to fall back to another font. This is a low-level debug
message, and should probably be silenced because it confuses me
every once in a while. :)
> Also it would be great if AbiWord could use .pfb files and fonts.dir
> files like the X server does, without having .pfa / .afm / .pfm files
> that can be generated from .pfb anyways.
Yes, right now it juse parses PFA files (for reasons of simplicity when
printing them in PostScript), but I intend to read PFB files and
do the necessary run-time conversion so more people can use more X fonts
if they have the metrics.
In fact, all the fonts in the distribution (GhostScript's font set)
were PFB files before I converted them with t1ascii and the t1utils
from http://www.lcdf.org/~eddietwo/type/.
-- Shaw Terwilliger