[Date Index][Thread Index]
[Date Prev][Date Next][Thread Prev][Thread Next]
Re: gfont problem...
- From: Dave Plonka <nospam@thanx>
- Date: Tue, 27 Jul 1999 16:58:09 -0500
On Tue, Jul 27, 1999 at 01:03:15AM +0200, Denis Barbier wrote:
> On Mon, 26 Jul 1999, John Bazik wrote:
>
> > I downloaded the latest gfont distribution, with the big-endian patch.
> > Works perfectly!
> >
> > One problem: I think the precompiled fonts are little-endian. I
> > regenerated them for myself and all is well. Include two sets or
> > generate during the build?
>
> Oops, you're right.
> Thanx for the point
Hmm, I think I should clarify something here - you *don't* want to
distribute two sets of fonts, the ".gdf" files _should_ now be portable.
(I tested the patch on Solaris SPARC and Linux Intel and also tested
that the ".gdf" files created after the patch are portable between
them.) The two things that I was addressing in that patch were:
1) make gfont work on big-endian architectures (e.g. Solaris SPARC)
2) make ".gdf" files portable
Previously, the problem was that gfont_pxtogdf would write *host order*
32-bit integers into the ".gdf" files, but then gfont expected them to be
little-endian when it read them. As such, it only worked properly on
little-endian platforms.
With the patch, gfont_pxtogdf will now always write *network order* (big-
endian) 32-bit values when creating ".gdf" files, and gfont will now
expect big-endian when reading the files, and swab them into *host order*
on little-endian platforms.
As an aside, if the maintainer/author would prefer not to invalidate
previously generated ".gdf" files for the current/large(?) little-endian
user base, the patch could be modified. The tests for WORDS_BIGENDIAN
simply would need to be reversed so that the ".gdf" files would then
always contain "little-endian" 32-bit integers, regardless of platform.
If this is done, a new snapshot should probably be done ASAP before more
confusion ensues. (I just chose big-endian because that's the canonical
"network order" with which we're all familiar.)
If the patch is left as-is (which I think is fine), it may help if the
docs (and probably ChangeLog) mention that, when upgrading from an older
gfont, users should remove and/or regenerate their existing installed
".gdf" and ".gdf.gz" files before "make install".
Lastly, one other thing I noticed in the new snapshot is that, regarding
Frederic's contribution (which he mentioned in the list that he integrated
with my "configure.in" patch), I believe it should say that it was to
improve the test of the perl version rather than handle big-endian
architectures, no? e.g.:
Changes between 1.0.2 and SNAP:
...
*) Check for big endian architecture (21-Jul-1999):
[Dave Plonka <plonka@doit.wisc.edu>]
*) Improve checking of perl version (21-Jul-1999):
[Frederic le Mouel <Frederic.LeMouel@irisa.fr>]
Thanks for the work Denis...
Dave
--
plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI
______________________________________________________________________
Website META Language (WML) www.engelschall.com/sw/wml/
Official Support Mailing List sw-wml@engelschall.com
Automated List Manager majordomo@engelschall.com