[
https://issues.apache.org/jira/browse/BATIK-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14322684#comment-14322684
]
Tilman Hausherr edited comment on BATIK-1109 at 2/16/15 11:54 AM:
------------------------------------------------------------------
Thanks to the good documentation :-) at
https://xmlgraphics.apache.org/batik/using/svg-generator.html I created a demo
that uses the font "Free Sans" (this is not the same contour as the one I
initially wrote about). Note the celsius symbol that isn't really round, it
looks irregular.
PDFBox is now using the code of PDF.js, which has an Apache license. Get it
here (now in java):
https://svn.apache.org/viewvc/pdfbox/trunk/fontbox/src/main/java/org/apache/fontbox/ttf/GlyphRenderer.java?view=markup
was (Author: tilman):
Thanks to the good documentation :-) at
https://xmlgraphics.apache.org/batik/using/svg-generator.html I created a demo
that uses the font "Free Sans" (this is not the same contour as the one I
initially wrote about). Note the celsius symbol that isn't really round, it
looks irregular.
PDFBox is now using the code of PDF.js, which has an Apache license. Get it
here (now in java):
https://svn.apache.org/viewvc/xmlgraphics/batik/trunk/sources/org/apache/batik/svggen/font/SVGFont.java?view=markup
> svggen.font.SVGFont doesn't always calculate the correct path
> -------------------------------------------------------------
>
> Key: BATIK-1109
> URL: https://issues.apache.org/jira/browse/BATIK-1109
> Project: Batik
> Issue Type: Bug
> Components: SVGGraphics2D
> Affects Versions: 1.7
> Reporter: Tilman Hausherr
> Attachments: FreeSans.ttf, TestSVGGen.java, test.svg
>
>
> We at PDFBox have used the code at
> https://svn.apache.org/viewvc/xmlgraphics/batik/trunk/sources/org/apache/batik/svggen/font/SVGFont.java?view=markup
> for TT font rendering. There've been some problems (see PDFBOX-1435, scroll
> to second half), and after bugfixes didn't work (see PDFBOX-1206), I had the
> idea to create a SVG file by hand with the calculations mentioned in the file.
> I calculated the SVG values for the outer circle of that "o" of PDFBOX-1435
> with the Batik source and added 100 to each y value (before I found out that
> svg allows translating). Here's the svg file I get:
> {code}
> <?xml version="1.0" standalone="no"?>
> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
> "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
> <svg width="12cm" height="12cm" viewBox="0 0 1200 1200"
> xmlns="http://www.w3.org/2000/svg"; version="1.1">
> <rect x="1" y="1" width="1000" height="1000"
> fill="none" stroke="blue" stroke-width="1" />
> <g transform="scale(7)">
> <path d="M85,53 T74,49 T54,48.5 T39.5,59.5 T35.5,76.5 T44,94 T62,102
> T79.5,97 T89.5,82.5 T88.5,63 Z"
> fill="none" stroke="red" stroke-width="5" />
> </g>
> </svg>
> {code}
> This can be displayed with firefox, and this "o" has an angle :-( The reason
> is that the Batik algorithm doesn't work for contours made entirely with
> off-curve points.
> I didn't actually run the Batik code, the calculations were done on paper.
> Further thoughts on the TT path drawing algorithm can be found at
> PDFBOX-1206. We ended up using the code from PDF.js, and maybe you should too
> :-)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-h...@xmlgraphics.apache.org
