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