Summary: | [PATCH] NPE when resolving substitutions for Arabic script | ||
---|---|---|---|
Product: | Batik - Now in Jira | Reporter: | Tor Arne Vestbø <torarnv> |
Component: | Utilities | Assignee: | Batik Developer's Mailing list <batik-dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | keith |
Priority: | P2 | Keywords: | PatchAvailable |
Version: | 1.8 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: |
Quick fix, dunno if it's safe to proceed if only one or two of the tree subsitutions were found, so I opted for the tripple-check, feel free to change.
Proposed fix v2 |
Description
Tor Arne Vestbø
2009-11-11 13:39:50 UTC
Actually the SVG produced seems to be broken, or at least missing tons of glyphs, so the fix fix might not be correct (it only fixes the NPE). I hit this exact same bug, NPE. Only for me it was on a font which I had processed with a subsetting tool (font-optimizer). I ended up applying the exact same patch to my local batik. Would be great to see this fix released. (In reply to comment #2) > I hit this exact same bug, NPE. Only for me it was on a font which I had > processed with a subsetting tool (font-optimizer). Are you able to attach the problematic font for further testing? > I ended up applying the > exact same patch to my local batik. Would be great to see this fix released. Thanks for confirming that the patch works around the issue. Currently, I was mostly trying to figure out if checking/setting each of the three variables would help avoiding too much information lost whenever only of them is missing. ;-) Thanks, Helder (In reply to comment #0) > ttf2svg crashes with NPE when processing DejaVuSans-Oblique from > http://dejavu.sourceforge.net/ (In reply to comment #1) > Actually the SVG produced seems to be broken, or at least missing tons of > glyphs, so the fix fix might not be correct (it only fixes the NPE). Thanks for the report. Are you able to provide the particular command line used in the conversion, including parameters [1], in order to help reproducing the issue? Thanks, Helder [1] http://xmlgraphics.apache.org/batik/tools/font-converter.html Created attachment 25987 [details] Proposed fix v2 (In reply to comment #0) > Quick fix, dunno if it's safe to proceed if only one or two of the tree > subsitutions were found, so I opted for the tripple-check, feel free to change. Yes, I've checked that the code later invoked in getGlyphAsSVG verifies each of them independently, so I've updated your patch proposal so that the checks are also independently made. :-) I've verified that, with the patch applied, the issue no longer occurs, although I'd like you to confirm it as well before committing it. @Keith Grennan Please confirm that the patch fixes the issue with your problematic font, otherwise please attach it as requested in comment 3. ;-) (In reply to comment #5) > I've verified that, with the patch applied, the issue no longer occurs [...] By the way, the command line during testing was: build ttf2svg DejaVuSans-Oblique.ttf -testcard I'm also adjusting the bug's title/metadata to reflect a patch being available, as well as assuming operating system as "All", as I was able to reproduce in Windows as well. (In reply to comment #1) > Actually the SVG produced seems to be broken, or at least missing tons of > glyphs [...] The miss of many glyphs probably has to do with not specifying the "-autorange" parameter (shown in command line but currently undocumented in the previous stated link [1], I'm working on it). Adding that to the command line makes Batik to try determining the glyphs in the font instead of using defaults (which seem range 32 to 128), which would explain the missing characters. :-) Again, try it as well and report back. ;-) [1] http://xmlgraphics.apache.org/batik/tools/font-converter.html (In reply to comment #7) > (In reply to comment #1) > > Actually the SVG produced seems to be broken, or at least missing tons of > > glyphs [...] > > The miss of many glyphs probably has to do with not specifying the "-autorange" > parameter (shown in command line but currently undocumented in the previous > stated link [1], I'm working on it). Adding that to the command line makes > Batik to try determining the glyphs in the font instead of using defaults > (which seem range 32 to 128), which would explain the missing characters. :-) > > Again, try it as well and report back. ;-) > > [1] http://xmlgraphics.apache.org/batik/tools/font-converter.html Your updated patch + '-autorange' seems to work fine here. Thanks! Committed in revision 996358 [1]. Thanks, everyone, for the help. :-) [1] http://svn.eu.apache.org/viewvc?view=revision&revision=996358 |