Well, I can patch over the problem by casting x and y to long(). I
still don't really understand why using a pen should cause the glyph
to return coordinates as singleton arrays rather than integers. Maybe
this indicates a deeper bug, and maybe not... I'll leave that up to
you to decide. :)
--- _g_l_y_f.py.bak 2007-10-01 13:54:05.000000000 -0700
+++ _g_l_y_f.py 2007-10-01 13:55:18.000000000 -0700
@@ -491,6 +491,7 @@
# Oh, the horrors of TrueType
flag = self.flags[i]
x, y = coordinates[i]
+ x, y = long(x), long(y)
# do x
if x == 0:
flag = flag | flagXsame
Thanks for your help!
-matt
On Oct 1 2007, 21:12, Just van Rossum wrote:
>It has something to do with how Numeric arrays these days return
>singleton arrays when getting a single value out of it, instead of
>ints; I'll try to have a better look tomorrow how you could solve this.
>
> >>> import Numeric
> >>> a = Numeric.array(range(5), Numeric.Int16)
> >>> type(a[3])
> <type 'array'>
> >>> a[3]
> 3
>
>Just
>
>On Oct 1, 2007, at 8:30 PM, Matt Chisholm wrote:
>
>>I've discovered that this has something to do with the pens. If I
>>just open the font and save it, I don't get the DeprecationWarnings.
>>However, my code is using both boundsPen and pointInsidePen, and if I
>>use *either* one of those pens, I get the DeprecationWarnings. If I
>>just return dummy values from my pointInside() and glyphBounds()
>>methods, and don't call glyph.draw(pen), I don't get the
>>DeprecationWarnings.
>>
>>Here's the relevant code:
>>
>> self.font = TTFont(fontpath)
>> self.glyphset = self.font.getGlyphSet()
>>
>> self.pipen = PointInsidePen(self.glyphset, (0,0)) # point
>>must be reset each time
>> self.bpen = BoundsPen(self.glyphset)
>>
>>
>> def pointInside(self, glyph, point):
>> self.pipen.setTestPoint(point) # point must be reset each time
>> glyph.draw(self.pipen)
>> return self.pipen.getResult()
>>
>>
>> def glyphBounds(self, glyph):
>> glyph.draw(self.bpen)
>> box = self.bpen.bounds
>> self.bpen.bounds = None # bounds must be reset for each glyph
>> return box
>>
>>Should I be making a copy of the glyph before calling draw()?
>>
>>-matt
>>
>>On Oct 1 2007, 10:50, Matt Chisholm wrote:
>>>I put a bunch of asserts into _g_l_y_f.Glyph.compileCoordinates(),
>>>and
>>>it turns out that sometimes the x (and possibly y) coordinates are
>>>not
>>>ints, they are arrays. Here's a faux diff:
>>>
>>> for i in range(len(coordinates)):
>>> # Oh, the horrors of TrueType
>>> flag = self.flags[i]
>>> x, y = coordinates[i]
>>> # do x
>>>+ try:
>>>+ assert(type(x) is int)
>>>+ except:
>>>+ raise Exception(str(type(x)))
>>> if x == 0:
>>> flag = flag | flagXsame
>>> elif -255 <= x <= 255:
>>> flag = flag | flagXShort
>>> if x > 0:
>>>
>>>And here's the traceback from the assert():
>>>
>>>Traceback (most recent call last):
>>> File "test.py", line 284, in <module>
>>> f.save()
>>> File "test.py", line 189, in save
>>> self.font.save(os.path.join('./test', n + '.test.ttf'))
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>__init__.py", line 177, in save
>>> self._writeTable(tag, writer, done)
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>__init__.py", line 532, in _writeTable
>>> self._writeTable(masterTable, writer, done)
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>__init__.py", line 532, in _writeTable
>>> self._writeTable(masterTable, writer, done)
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>__init__.py", line 535, in _writeTable
>>> tabledata = self.getTableData(tag)
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>__init__.py", line 547, in getTableData
>>> return self.tables[tag].compile(self)
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>tables/_g_l_y_f.py", line 57, in compile
>>> glyphData = glyph.compile(self, recalcBBoxes)
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>tables/_g_l_y_f.py", line 233, in compile
>>> data = data + self.compileCoordinates()
>>> File "/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/
>>>tables/_g_l_y_f.py", line 498, in compileCoordinates
>>> raise Exception(str(type(x)))
>>>Exception: <type 'array'>
>>>
>>>
>>>These assert()s also trigger under Python 2.4, but the
>>>DeprecationWarnings don't happen under 2.4. So it would seem that
>>>Python 2.5's struct doesn't like to coerce array types to integers,
>>>but Python 2.4's struct doesn't mind.
>>>
>>>I'm in way over my head here... never worked with struct or array
>>>before, and I don't really understand the weird packing into bytes or
>>>shorts, with 'compressedFlags,' that this function is doing. Thanks
>>>for looking at it.
>>>
>>>-matt
>>>
>>>On Oct 1 2007, 10:44, Just van Rossum wrote:
>>>>Hmm, this shouldn't happen unless you try to feed it coordinates
>>>>that
>>>>don't fit into a 2 byte signed integer. Can you verify whether this
>>>>is the case or not?
>>>>
>>>>Just
>>>>
>>>>On Oct 1, 2007, at 10:04 AM, Matt Chisholm wrote:
>>>>
>>>>>Hi. I get the following two DeprecationWarnings in
>>>>>fontTools.ttLib.tables._g_l_y_f.py, in Glyph.compileCoordinates().
>>>>>That code path is executed when calling TTFont.save():
>>>>>
>>>>>/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/tables/
>>>>>_g_l_y_f.py:537: DeprecationWarning: struct integer overflow
>>>>>masking is deprecated
>>>>> data = data + apply(struct.pack, (xFormat,)+tuple(xPoints))
>>>>>
>>>>>/usr/lib/python2.5/site-packages/FontTools/fontTools/ttLib/tables/
>>>>>_g_l_y_f.py:538: DeprecationWarning: struct integer overflow
>>>>>masking is deprecated
>>>>> data = data + apply(struct.pack, (yFormat,)+tuple(yPoints))
>>>>>
>>>>>I'm running Python 2.5.1, and fontTools 1.99+2.0b1
>>>>>+cvs20060225-1build1
>>>>>(the version that comes with Ubuntu 7.04)
>>>>>
>>>>>I've seen other similar DeprecationWarnings under 2.5 elsewhere,
>>>>>like
>>>>>in the _k_e_r_n classes. I believe this DeprecationWarning
>>>>>means that
>>>>>this code will eventually break under some later version of
>>>>>Python. I
>>>>>tried to figure out a fix but I don't understand the TrueType
>>>>>format
>>>>>or the behavior of struct() well enough to fix it. Any ideas?
>>>>>
>>>>>-matt
>>>>>
>>>>>ps. This message is also an attempt to see if this mailing list is
>>>>>still alive, since the SourceForge archive has only spam.
>>>>>
>>>>>
>>>>>-------------------------------------------------------------------
>>>>>---
>>>>>---
>>>>>This SF.net email is sponsored by: Microsoft
>>>>>Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>>>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>_______________________________________________
>>>>>FontTools-discussion mailing list
>>>>>FontTools-discussion@...
>>>>>https://lists.sourceforge.net/lists/listinfo/fonttools-discussion
>>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>----
>>>This SF.net email is sponsored by: Microsoft
>>>Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>_______________________________________________
>>>FontTools-discussion mailing list
>>>FontTools-discussion@...
>>>https://lists.sourceforge.net/lists/listinfo/fonttools-discussion
>>
>
|