I've found the bug.  It turns out that in this document, the y-coordinate
overflows the bounds of Int16.  This is a problem.  The y-distance in a
document should NOT be stored in an Int16.  Nor should the height in the
metarecords.  One CAN overflow this, as the document I have shows.  (It's
also easy to see that one can overflow this.  Think about the fact that a
large character is about 28-pixels high.  One might have a line spacing of
up to 4.  There will be about 30-characters per line.  Some back of the
envelope type calculations show it is possible to overflow 32767 in a
record of the size Plucker allows.)

What to do?  I guess we need to promote a whole bunch of Int16s to
Int32s.  This is going to degrade performance, but I see no cure.  We need
to do this in TextContext, and elsewhere.  How do we make sure we haven't
missed anything?

--
Dr. Alexander R. Pruss  || e-mail: [EMAIL PROTECTED]
Philosophy Department   || online papers and home page:
Georgetown University   ||  www.georgetown.edu/faculty/ap85
Washington, DC 20057    ||
U.S.A.                  ||
-----------------------------------------------------------------------------
   "Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur."
       - Paul of Worczyn (1424)

_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev

Reply via email to