linxingang / sfntly

Automatically exported from code.google.com/p/sfntly
0 stars 0 forks source link

Inconsistent behaviour in reading a font from a byte array vs input stream #28

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Run the attached class with either 'byte' or 'filestream' as input parameters
2. Compare the output for each case

What is the expected output? What do you see instead?
There behaviour should be consistent, independent of how the font was loaded.

What version of the product are you using? On what operating system?
r147, Windows XP

Please provide any additional information below.
When calling Glyph.xMin() for glyph id 1012 (corresponding to U+0020/SPACE for 
the attached font), an IndexOutOfBounds exception will be thrown iff loaded 
from a file input stream. This is not observed if loaded from a byte array.

Original issue reported on code.google.com by tinned...@yahoo.com on 26 Jan 2013 at 3:12

Attachments:

GoogleCodeExporter commented 9 years ago
Here's a version using Roboto Regular

With this font the error occurs with U+0009/CHARACTER TABULATION (glyph id 1036)

Original comment by tinned...@yahoo.com on 27 Jan 2013 at 8:35

Attachments:

GoogleCodeExporter commented 9 years ago
Yeah, they both should be throwing an exception when read from.

One thing to think about is that it is entirely legal to have a glyph of zero 
size in the glyf table or to have a non-zero size one with zero contours. Both 
of these cases can be checked by asking for the number of contours and if it is 
zero then not making other calls to the glyph object. In any real code you 
should wrap you glyph query code with a call to the contour check.

Original comment by stua...@google.com on 5 Feb 2013 at 2:18

GoogleCodeExporter commented 9 years ago
Fixed with r155.

Original comment by stua...@google.com on 30 Mar 2013 at 12:48