[jira] [Commented] (FOP-2504) [PATCH] Truetype support for AFP
[
https://issues.apache.org/jira/browse/FOP-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659827#comment-14659827
]
simon steiner commented on FOP-2504:
Added
http://svn.apache.org/viewvc?view=revisionrevision=1694449
http://svn.apache.org/viewvc?view=revisionrevision=1694450
[PATCH] Truetype support for AFP
Key: FOP-2504
URL: https://issues.apache.org/jira/browse/FOP-2504
Project: FOP
Issue Type: Bug
Reporter: simon steiner
Assignee: simon steiner
Attachments: truetypeafp.patch, xgctruetypeafp.patch
You may need to restart Infoprint server before printing due to bugs in
printer driver.
Subsetting is not supported
Add to fop.xconf:
{code}
renderer mime=application/x-afp
fonts
font embed-url=Arial.ttf name=Arial
font-triplet name=Arial style=normal weight=normal/
font-triplet name=any style=normal weight=normal/
/font
/fonts
/renderer
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: SingleByteFont Patch
Hi Team,
the same issue described below, came up today on my side. I did a debug
session and what I have found out so far is, that this only happens for
Type1 fonts, that don't have a AFM file. The PFM file doesn't contain
the char metrics so the bounding boxes can't be initialized.
When transcoding SVGs to PDF, the code seems to rely on those bounding
boxes (see FOPGVTGlyphVector), so I'm wondering what a correct fix would
be. The PFMFile class contains a getFontBBox method, which, as its
JavaDoc says, returns an approximation of the bounding box. I guess
returning the approximation is better than nothing, so what I've come up
so far code-wise is:
returnFont.setLastChar(pfm.getLastChar());
for (short i = pfm.getFirstChar(); i = pfm.getLastChar(); i++) {
int cw = pfm.getCharWidth(i);
singleFont.setWidth(i, cw);
// start of my code change
int[] bbox = pfm.getFontBBox();
singleFont.setBoundingBox(i, new Rectangle(bbox[0], bbox[1], cw,
bbox[3]));
// end of my code change
}
Basically I'm using the approximation plus the current char width to
build a rectangle.
Any thoughts? Or ideas for a better fix?
Thanks Best regards,
Matthias
On 01.07.2014 08:43, Pascal Sancho wrote:
Hi,
can you file in entries in Jira, please?
see our HowTo [1] submitting patches.
[1] http://xmlgraphics.apache.org/fop/dev/#patches
2014-07-01 12:36 GMT+02:00 Kai Hofmann powers...@web.de:
Dear all,
looks like there is another bug based on the before mentioned problem:
FOPGVTGlyphVector:
private void buildBoundingBoxes() {
boundingBoxes = new Rectangle2D[glyphs.length];
for (int i = 0; i glyphs.length; i++) {
Rectangle bbox = fontMetrics.getBoundingBox(glyphs[i], fontSize);
boundingBoxes[i] = new Rectangle2D.Float(bbox.x / 100f,
-(bbox.y + bbox.height) / 100f,
bbox.width / 100f, bbox.height / 100f);
}
}
Here the result of the patched getBoundingBox seems to be used without a
null pointer check. Please keep attention on getBoundingBox which explizitly
returns null
Looks like it would help to have complete javadocs which describe the
possible return values to avoid such mistakes.
Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr
Von: Kai Hofmann powers...@web.de
An: fop-us...@xmlgraphics.apache.org
Betreff: SingleByteFont Patch
Dear all,
I found a small bug in SingleByteFont - please see attached patch - in
getBoundingBox:
if (idx = 0 idx boundingBoxes.length)
might result in a null pointer exception, when getBoundingBox is called
before setBoudning box.
So repleace with:
if (boundingBoxes != null idx = 0 idx boundingBoxes.length)
[jira] [Commented] (FOP-2504) [PATCH] Truetype support for AFP
[
https://issues.apache.org/jira/browse/FOP-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659839#comment-14659839
]
simon steiner commented on FOP-2504:
http://svn.apache.org/viewvc?view=revisionrevision=1694452
[PATCH] Truetype support for AFP
Key: FOP-2504
URL: https://issues.apache.org/jira/browse/FOP-2504
Project: FOP
Issue Type: Bug
Reporter: simon steiner
Assignee: simon steiner
Attachments: truetypeafp.patch, xgctruetypeafp.patch
You may need to restart Infoprint server before printing due to bugs in
printer driver.
Subsetting is not supported
Add to fop.xconf:
{code}
renderer mime=application/x-afp
fonts
font embed-url=Arial.ttf name=Arial
font-triplet name=Arial style=normal weight=normal/
font-triplet name=any style=normal weight=normal/
/font
/fonts
/renderer
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
RE: [VOTE] Merge Temp_PCLSoftFont branch with trunk
Hi, +1 Thanks From: Robert Meyer [mailto:rme...@hotmail.co.uk] Sent: 04 August 2015 16:33 To: fop-dev@xmlgraphics.apache.org Subject: [VOTE] Merge Temp_PCLSoftFont branch with trunk Hi All, This is a vote to merge the temporary branch for adding PCL soft font support to FOP trunk. What this allows for are TrueType fonts to be converted into a PCL native font format. This moves FOP away from using AWT and rasterized characters allowing for PCL output to potentially be generated over a cloud, better rendering quality and smaller documents. Other font formats will still be rasterized but TrueType will now default to being converted for PCL output. If you want to give it a try please do. The branch can be found here: http://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFont s https://svn.eu.apache.org/repos/asf/xmlgraphics/fop/branches/Temp_PCLSoftFo nts This vote wll last 6 days (as I'm unavailable this weekend) and will conclude next Monday. Here is my +1. Thanks, Robert
[jira] [Closed] (FOP-2504) [PATCH] Truetype support for AFP
[
https://issues.apache.org/jira/browse/FOP-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
simon steiner closed FOP-2504.
--
Resolution: Fixed
[PATCH] Truetype support for AFP
Key: FOP-2504
URL: https://issues.apache.org/jira/browse/FOP-2504
Project: FOP
Issue Type: Bug
Reporter: simon steiner
Assignee: simon steiner
Attachments: truetypeafp.patch, xgctruetypeafp.patch
You may need to restart Infoprint server before printing due to bugs in
printer driver.
Subsetting is not supported
Add to fop.xconf:
{code}
renderer mime=application/x-afp
fonts
font embed-url=Arial.ttf name=Arial
font-triplet name=Arial style=normal weight=normal/
font-triplet name=any style=normal weight=normal/
/font
/fonts
/renderer
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
RE: SingleByteFont Patch
Hi,
I have had dealings with this when I was implementing open-type font support as
that and Type-1 fonts share similar CharString data. Initially I thought the
bounding box was a necessary part of getting the font to work and as such put
forward two patches to FontBox. The first fixed their CharStringRenderer which
renders each character and returns the width:
https://issues.apache.org/jira/browse/PDFBOX-1505
Once that was approved, I put forward a second patch which calculated an
accurate bounding box for the given character using the same renderer:
https://issues.apache.org/jira/browse/PDFBOX-1645
Unfortunately doing this takes a fair amount of processing power and after
reading some of their concerns, while also realising that in the end I didn't
need the bounding box, I gave up on my attempt and the issue was closed. From
my testing it was certainly possible to get very accurate bounding boxes for
Type 1 font missing metrics. Whether it would be worth the effort implementing
this is doubtful though considering firstly the fact that we lack much of the
infrastructure to implement this, but more importantly having a detrimental
impact upon performance for these limited cases.
If Jeremias's approximation is anywhere near accurate I'd certainly suggest
giving that a go.
Robert
Date: Thu, 6 Aug 2015 09:42:12 -0300
From: matthias8...@gmx.at
To: fop-dev@xmlgraphics.apache.org
Subject: Re: SingleByteFont Patch
Hi Team,
the same issue described below, came up today on my side. I did a debug
session and what I have found out so far is, that this only happens for
Type1 fonts, that don't have a AFM file. The PFM file doesn't contain
the char metrics so the bounding boxes can't be initialized.
When transcoding SVGs to PDF, the code seems to rely on those bounding
boxes (see FOPGVTGlyphVector), so I'm wondering what a correct fix would
be. The PFMFile class contains a getFontBBox method, which, as its
JavaDoc says, returns an approximation of the bounding box. I guess
returning the approximation is better than nothing, so what I've come up
so far code-wise is:
returnFont.setLastChar(pfm.getLastChar());
for (short i = pfm.getFirstChar(); i = pfm.getLastChar(); i++) {
int cw = pfm.getCharWidth(i);
singleFont.setWidth(i, cw);
// start of my code change
int[] bbox = pfm.getFontBBox();
singleFont.setBoundingBox(i, new Rectangle(bbox[0], bbox[1], cw,
bbox[3]));
// end of my code change
}
Basically I'm using the approximation plus the current char width to
build a rectangle.
Any thoughts? Or ideas for a better fix?
Thanks Best regards,
Matthias
On 01.07.2014 08:43, Pascal Sancho wrote:
Hi,
can you file in entries in Jira, please?
see our HowTo [1] submitting patches.
[1] http://xmlgraphics.apache.org/fop/dev/#patches
2014-07-01 12:36 GMT+02:00 Kai Hofmann powers...@web.de:
Dear all,
looks like there is another bug based on the before mentioned problem:
FOPGVTGlyphVector:
private void buildBoundingBoxes() {
boundingBoxes = new Rectangle2D[glyphs.length];
for (int i = 0; i glyphs.length; i++) {
Rectangle bbox = fontMetrics.getBoundingBox(glyphs[i],
fontSize);
boundingBoxes[i] = new Rectangle2D.Float(bbox.x / 100f,
-(bbox.y + bbox.height) / 100f,
bbox.width / 100f, bbox.height / 100f);
}
}
Here the result of the patched getBoundingBox seems to be used without a
null pointer check. Please keep attention on getBoundingBox which
explizitly returns null
Looks like it would help to have complete javadocs which describe the
possible return values to avoid such mistakes.
Gesendet: Dienstag, 01. Juli 2014 um 10:52 Uhr
Von: Kai Hofmann powers...@web.de
An: fop-us...@xmlgraphics.apache.org
Betreff: SingleByteFont Patch
Dear all,
I found a small bug in SingleByteFont - please see attached patch - in
getBoundingBox:
if (idx = 0 idx boundingBoxes.length)
might result in a null pointer exception, when getBoundingBox is called
before setBoudning box.
So repleace with:
if (boundingBoxes != null idx = 0 idx boundingBoxes.length)
