Automatic text overprint patch
Hello,
I've implemented a small patch which allows to automatically set the
overprint state for text in pdf output. This is useful when text and
background colors are printed on different printing plates because it
ensures that no white spaces are visible if the printing plates are not
positioned perfectly.
See also: http://www.nabble.com/Overprint-Black-Text-td9852903.html
Feel free to review or integrate it into fop trunk if it's for any use
to you.
Usage:
foUserAgent.getRendererOptions().put(PDFConfigurationConstants.KEY_ENABLE_AUTO_OVERPRINT,
Boolean.TRUE);
Regards,
Matthias Reischenbacher
__ Information from ESET NOD32 Antivirus, version of virus signature
database 4470 (20090930) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Index: src/java/org/apache/fop/pdf/PDFGState.java
===
--- src/java/org/apache/fop/pdf/PDFGState.java (revision 820021)
+++ src/java/org/apache/fop/pdf/PDFGState.java (working copy)
@@ -153,6 +153,9 @@
sb.append(\n/Type /ExtGState\n);
appendVal(sb, GSTATE_ALPHA_NONSTROKE);
appendVal(sb, GSTATE_ALPHA_STROKE);
+appendVal(sb, GSTATE_OVERPRINT_FILL);
+appendVal(sb, GSTATE_OVERPRINT_MODE);
+appendVal(sb, GSTATE_OVERPRINT_STROKE);
sb.append(\nendobj\n);
return sb.toString();
Index: src/java/org/apache/fop/render/pdf/PDFConfigurationConstants.java
===
--- src/java/org/apache/fop/render/pdf/PDFConfigurationConstants.java
(revision 820021)
+++ src/java/org/apache/fop/render/pdf/PDFConfigurationConstants.java
(working copy)
@@ -49,4 +49,7 @@
* PDF/X profile is active).
*/
String KEY_DISABLE_SRGB_COLORSPACE = disable-srgb-colorspace;
+
+/** Rendering Options key for enabling automatic text overprinting. */
+String KEY_ENABLE_AUTO_OVERPRINT = auto-overprint-enabled;
}
Index: src/java/org/apache/fop/render/pdf/PDFPainter.java
===
--- src/java/org/apache/fop/render/pdf/PDFPainter.java (revision 820021)
+++ src/java/org/apache/fop/render/pdf/PDFPainter.java (working copy)
@@ -26,6 +26,8 @@
import java.awt.Rectangle;
import java.awt.geom.AffineTransform;
import java.io.IOException;
+import java.util.HashMap;
+import java.util.Map;
import org.w3c.dom.Document;
@@ -39,6 +41,7 @@
import org.apache.fop.fonts.SingleByteFont;
import org.apache.fop.fonts.Typeface;
import org.apache.fop.pdf.PDFDocument;
+import org.apache.fop.pdf.PDFGState;
import org.apache.fop.pdf.PDFNumber;
import org.apache.fop.pdf.PDFTextUtil;
import org.apache.fop.pdf.PDFXObject;
@@ -59,6 +62,14 @@
/** logging instance */
private static Log log = LogFactory.getLog(PDFPainter.class);
+/** Graphic state settings with overprinting enabled */
+private static Map overprintGStateSettings = new HashMap();
+static {
+overprintGStateSettings.put(PDFGState.GSTATE_OVERPRINT_STROKE,
Boolean.TRUE);
+overprintGStateSettings.put(PDFGState.GSTATE_OVERPRINT_FILL,
Boolean.TRUE);
+overprintGStateSettings.put(PDFGState.GSTATE_OVERPRINT_MODE, new
Integer(1));
+}
+
private PDFDocumentHandler documentHandler;
/** The current content generator */
@@ -255,6 +266,25 @@
/** {...@inheritdoc} */
public void drawText(int x, int y, int letterSpacing, int wordSpacing,
int[] dx, String text)
throws IFException {
+boolean useOverprint = false;
+if (this.getPDFUtil().isAutoOverpintEnabled()) {
+Color backColor = generator.currentState.getBackColor();
+Color textColor = state.getTextColor();
+useOverprint = !backColor.equals(Color.white)
!textColor.equals(Color.white)
+ !textColor.equals(backColor);
+}
+
+if (useOverprint) {
+generator.saveGraphicsState();
+
+PDFGState gstate =
this.getPDFDoc().getFactory().makeGState(overprintGStateSettings,
+generator.getState().getGState());
+
+documentHandler.pdfResources.addGState(gstate);
+
+generator.add(/ + gstate.getName() + gs\n);
+}
+
generator.updateColor(state.getTextColor(), true, null);
generator.beginTextObject();
FontTriplet triplet = new FontTriplet(
@@ -330,6 +360,10 @@
}
textutil.writeTJ();
+
+if (useOverprint) {
+generator.restoreGraphicsState();
+}
}
}
Index: src/java/org/apache/fop/render/pdf/PDFRenderingUtil.java
===
--- src/java/org/apache/fop/render/pdf/PDFRenderingUtil.java(revision
820021)
+++ src/java/org/apache/fop/render/pdf/PDFRenderingUtil.java(working copy)
@@ -91,6 +91,7 @@
/** Optional URI to an output
Re: Automatic text overprint patch
Hi Jeremias, ok done. Here's the bugzilla link: https://issues.apache.org/bugzilla/show_bug.cgi?id=47927 Regards, Matthias Jeremias Maerki wrote: Matthias, please attach your patch to a new Bugzilla entry: https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop That way we can better keep track of it and it doesn't get lost so easily in the noise. Thanks! On 30.09.2009 18:58:46 Matthias Reischenbacher wrote: Hello, I've implemented a small patch which allows to automatically set the overprint state for text in pdf output. This is useful when text and background colors are printed on different printing plates because it ensures that no white spaces are visible if the printing plates are not positioned perfectly. See also: http://www.nabble.com/Overprint-Black-Text-td9852903.html Feel free to review or integrate it into fop trunk if it's for any use to you. Usage: foUserAgent.getRendererOptions().put(PDFConfigurationConstants.KEY_ENABLE_AUTO_OVERPRINT, Boolean.TRUE); Regards, Matthias Reischenbacher __ Information from ESET NOD32 Antivirus, version of virus signature database 4470 (20090930) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Jeremias Maerki - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 4471 (20090930) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4473 (20091001) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Footnotes broken?
Hi, with FOP-Trunk (Rev 822329) I'm getting a NPE when using footnotes. That's the markup I have tried: fo:block line-height=120% orphans=3 space-after=12pt space-before=3pt widows=4 par test fußnote: fo:footnote fo:inline baseline-shift=super font-size=8pt1/fo:inline fo:footnote-body fo:block1 oh yeah/fo:block /fo:footnote-body /fo:footnote aslödkfj. /fo:block Am I doing something wrong or is this feature broken? Thanks Regards, Matthias Reischenbacher Here is the stack trace: java.lang.NullPointerException at org.apache.fop.layoutmgr.PageBreakingAlgorithm.handleFootnotes(PageBreakingAlgorithm.java:352) at org.apache.fop.layoutmgr.PageBreakingAlgorithm.handleBox(PageBreakingAlgorithm.java:302) at org.apache.fop.layoutmgr.BreakingAlgorithm.handleElementAt(BreakingAlgorithm.java:655) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:490) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:439) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:368) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElementsAbsolute(BlockContainerLayoutManager.java:817) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(BlockContainerLayoutManager.java:198) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:199) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:140) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:129) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:70) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:216) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:682) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:149) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:132) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:336) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102) at org.apache.xml.serializer.TreeWalker.endNode(TreeWalker.java:460) at org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:151) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) __ Information from ESET NOD32 Antivirus, version of virus signature database 4533 (20091022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Footnotes broken?
Hi, I've did some further testing on this issue and I created a small test case which reproduces the exception. The error has to do with an absolute positioned block container. Please find attached the fo file (footnote_in_absolute_block-container.fo). Any hints how I could fix this error in the FOP-trunk code? Regards, Matthias Reischenbacher Matthias Reischenbacher wrote: Hi, with FOP-Trunk (Rev 822329) I'm getting a NPE when using footnotes. That's the markup I have tried: fo:block line-height=120% orphans=3 space-after=12pt space-before=3pt widows=4 par test fußnote: fo:footnote fo:inline baseline-shift=super font-size=8pt1/fo:inline fo:footnote-body fo:block1 oh yeah/fo:block /fo:footnote-body /fo:footnote aslödkfj. /fo:block Am I doing something wrong or is this feature broken? Thanks Regards, Matthias Reischenbacher Here is the stack trace: java.lang.NullPointerException at org.apache.fop.layoutmgr.PageBreakingAlgorithm.handleFootnotes(PageBreakingAlgorithm.java:352) at org.apache.fop.layoutmgr.PageBreakingAlgorithm.handleBox(PageBreakingAlgorithm.java:302) at org.apache.fop.layoutmgr.BreakingAlgorithm.handleElementAt(BreakingAlgorithm.java:655) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:490) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:439) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:368) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElementsAbsolute(BlockContainerLayoutManager.java:817) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(BlockContainerLayoutManager.java:198) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:199) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:140) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:129) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:70) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:216) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:682) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:149) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:132) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:336) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102) at org.apache.xml.serializer.TreeWalker.endNode(TreeWalker.java:460) at org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:151) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) __ Information from ESET NOD32 Antivirus, version of virus signature database 4533 (20091022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 4533 (20091022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4541 (20091025) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=normal page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body fo:block-container absolute-position=absolute height=100mm left=50mm top=50mm width=100mm fo:block This is a block with a footnotefo:footnote fo:inline font-size=50% vertical-align=top1/fo:inline fo:footnote-body fo:block fo:inline font-size=50% vertical-align=top1/fo:inlineI'm a footnote
Re: Footnotes broken?
Hi, after debugging the code I think have a possible solution for this error. Please have a look at the patch I submitted: https://issues.apache.org/bugzilla/show_bug.cgi?id=48053 Regards, Matthias Reischenbacher Matthias Reischenbacher wrote: Hi, I've did some further testing on this issue and I created a small test case which reproduces the exception. The error has to do with an absolute positioned block container. Please find attached the fo file (footnote_in_absolute_block-container.fo). Any hints how I could fix this error in the FOP-trunk code? Regards, Matthias Reischenbacher Matthias Reischenbacher wrote: Hi, with FOP-Trunk (Rev 822329) I'm getting a NPE when using footnotes. That's the markup I have tried: fo:block line-height=120% orphans=3 space-after=12pt space-before=3pt widows=4 par test fußnote: fo:footnote fo:inline baseline-shift=super font-size=8pt1/fo:inline fo:footnote-body fo:block1 oh yeah/fo:block /fo:footnote-body /fo:footnote aslödkfj. /fo:block Am I doing something wrong or is this feature broken? Thanks Regards, Matthias Reischenbacher Here is the stack trace: java.lang.NullPointerException at org.apache.fop.layoutmgr.PageBreakingAlgorithm.handleFootnotes(PageBreakingAlgorithm.java:352) at org.apache.fop.layoutmgr.PageBreakingAlgorithm.handleBox(PageBreakingAlgorithm.java:302) at org.apache.fop.layoutmgr.BreakingAlgorithm.handleElementAt(BreakingAlgorithm.java:655) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:490) at org.apache.fop.layoutmgr.BreakingAlgorithm.findBreakingPoints(BreakingAlgorithm.java:439) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:368) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElementsAbsolute(BlockContainerLayoutManager.java:817) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(BlockContainerLayoutManager.java:198) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:199) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:140) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:129) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:70) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:216) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:682) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:149) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:132) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:336) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) at org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1102) at org.apache.xml.serializer.TreeWalker.endNode(TreeWalker.java:460) at org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:151) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390) __ Information from ESET NOD32 Antivirus, version of virus signature database 4533 (20091022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 4533 (20091022) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4541 (20091025) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4541 (20091025) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail
Symbol and Wingdings Font support
Hi, I've tested the new support for Symbol and Wingdings fonts with the latest FOP trunk and wanted to share with you two observations: 1. In my fop config file font auto detection is enabled. Nevertheless Wingdings and Symbol fonts are not automatically detected inside the Windows Fonts folder. I had to copy the .ttf files inside the folder where my font base url is pointing to (fopFactory.getFontManager().setFontBaseURL()). Then it worked just fine. Generating the font metrics was not necessary and neither did I have to declare the fonts explicitly in the fop config file. 2. I've also tried to use the Symbol font inside SVGs, especially with the Ohm-character. But the Ohm-character is not displayed correctly because a fallback is done to Helvetica. That's strange because when inserting the ohm-Symbol as normal text inside a fo:block element it worked without any problem. I'm attaching a sample SVG file. Could you please tell me if I'm doing something wrong or if this is a FOP bug? Thanks Regards, Matthias Reischenbacher attachment: ohm_problem.svg - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Symbol and Wingdings Font support
Hi Jeremias, I've tested the new support for Symbol and Wingdings fonts with the latest FOP trunk and wanted to share with you two observations: 1. In my fop config file font auto detection is enabled. Nevertheless Wingdings and Symbol fonts are not automatically detected inside the Windows Fonts folder. I had to copy the .ttf files inside the folder where my font base url is pointing to (fopFactory.getFontManager().setFontBaseURL()). Then it worked just fine. Generating the font metrics was not necessary and neither did I have to declare the fonts explicitly in the fop config file. I noticed something similar myself lately. Took me hours to track down. In the end, it was this: FOP's font cache file [1] was still carrying the information that Symbol and Wingdings have not been loaded successfully (with the previous FOP version). That's why FOP won't load the font. Once you delete the cache file I expect FOP to find the two fonts in the Windows Fonts folder. Maybe I should have changed the serialization version number for the font cache so it is deleted automatically. [1]HOME/.fop/fop-fonts.cache Thanks for the tip, that was the problem also in my case. 2. I've also tried to use the Symbol font inside SVGs, especially with the Ohm-character. But the Ohm-character is not displayed correctly because a fallback is done to Helvetica. That's strange because when inserting the ohm-Symbol as normal text inside a fo:block element it worked without any problem. I'm attaching a sample SVG file. Could you please tell me if I'm doing something wrong or if this is a FOP bug? You're using the Ohm Glyph from Unicode:#x2126; But FOP does not currently map the Symbol TTF font into the right Unicode codepoints where possible (we'd probably need a heuristic for that). Instead everything is mapped into F020 to F0FF and 0020 to 00FF. I expect #xF057; to work for the Ohm symbol. Not optimal, I know. Using 2126 with the Arial Unicode MS should work, though. Using #xF057; did work as you said. Actually I had inserted the unicode character myself. The original SVG file contained the letter W instead of the unicode character. Would it be possible (and valid) to map the letter to its representation in the Symbol font? Doing this actually works inside fo:block, but I'm aware of what you said in your last post about the differences in font handling between Batik and FOP. Thanks for you help! Regards, Matthias Reischenbacher - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Use of soft hyphen causes IllegalArgumentException in some cases
Hi, I think the changes introduced in FOP trunk by the patch of bugzilla entry #48071 are causing an IllegalArgumentException in some cases. Specifically the exception occurs when a soft hyphen character is used and it is surrounded by white spaces. I know that this doesn't make much sense because the white space would trigger a linebreak anyway but I think it would be better to log a warn message instead of throwing the exception. Attached you'll find a sample fo file which reproduces the error. Should I add a new bugzilla entry? Can anyone fix this please? Regards, Matthias Reischenbacher The complete stacktrace: java.lang.IllegalArgumentException: factor 0; was: -1 at org.apache.fop.traits.MinOptMax.mult(MinOptMax.java:251) at org.apache.fop.layoutmgr.inline.TextLayoutManager.processWord(TextLayoutManager.java:825) at org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(TextLayoutManager.java:710) at org.apache.fop.layoutmgr.inline.LineLayoutManager.collectInlineKnuthElements(LineLayoutManager.java:639) at org.apache.fop.layoutmgr.inline.LineLayoutManager.getNextKnuthElements(LineLayoutManager.java:579) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.BlockContainerLayoutManager.getNextKnuthElements(BlockContainerLayoutManager.java:287) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:571) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextChildElements(BlockStackingLayoutManager.java:552) at org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:280) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:123) at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:115) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextChildElements(FlowLayoutManager.java:199) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:140) at org.apache.fop.layoutmgr.FlowLayoutManager.addChildElements(FlowLayoutManager.java:129) at org.apache.fop.layoutmgr.FlowLayoutManager.getNextKnuthElements(FlowLayoutManager.java:70) at org.apache.fop.layoutmgr.PageBreaker.getNextKnuthElements(PageBreaker.java:216) at org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:697) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:149) at org.apache.fop.layoutmgr.PageBreaker.getNextBlockList(PageBreaker.java:132) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:341) at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177) ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; language=en hyphenate=true fo:layout-master-set fo:simple-page-master master-name=simple page-height=5in page-width=5in fo:region-body
Re: PNG vs JPG in performance
Hi Adam, I think the cause of the 30sec delay is that PNGs aren't embedded natively into the PDF and they must be transcoded first. It would be really nice, if the FOP-Team could fix this issue, since this problem also occurs when using PNGs inside SVGs and converting PNGs to JPEGs isn't so easy in this case. Regards, Matthias On 13.08.2010 08:41, Adam Kovacs wrote: Hi there! Im currently having a strange effect. I use PNG images in my XSL to create PDFs. I have real performance problems (the XSL is quite complex and looks fancy with many images) If I use PNGs it takes 30s to create a PDF. If I use JPGs it takes only 2,5s to create the same PDF (JPGs created from the PNGs) Im creating the PDFs over the FOP_IF and with concatenation of more FOP_IF files. Can anybody explain this to me? I would need to use PNGs as the printer likes them more. Is there any other format which is even more faster? (Giff or anything else?) Thanks in advance!!! *Adam * *Using FOP 1.0* __ Information from ESET NOD32 Antivirus, version of virus signature database 5363 (20100813) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: PNG vs JPG in performance
Jeremias, do you have a patch file of your work with PNG? Perhaps with a second pair of eyes we could resolve that issue... ;-) Regards, Matthias On 13.08.2010 12:06, Jeremias Maerki wrote: Matthias is right. The PNGs need to be decoded and re-encoded. Some time ago I've made experiments to embed PNG files without re-encoding them but I haven't gotten that to work. Somehow the data was not quite right so Acrobat barked at me with its usual unhelpful error messages. :-( At the moment the only data formats we can embed without re-encoding are JPEG and CCITT Group 3 and 4. BTW, inside PDF there's no such thing as PNG or GIF. PDF uses its own representation of bitmap images. So that means we always have to interpret an image file and convert it to PDFs internal objects. On 13.08.2010 14:37:44 Matthias Reischenbacher wrote: Hi Adam, I think the cause of the 30sec delay is that PNGs aren't embedded natively into the PDF and they must be transcoded first. It would be really nice, if the FOP-Team could fix this issue, since this problem also occurs when using PNGs inside SVGs and converting PNGs to JPEGs isn't so easy in this case. Regards, Matthias On 13.08.2010 08:41, Adam Kovacs wrote: Hi there! Im currently having a strange effect. I use PNG images in my XSL to create PDFs. I have real performance problems (the XSL is quite complex and looks fancy with many images) If I use PNGs it takes 30s to create a PDF. If I use JPGs it takes only 2,5s to create the same PDF (JPGs created from the PNGs) Im creating the PDFs over the FOP_IF and with concatenation of more FOP_IF files. Can anybody explain this to me? I would need to use PNGs as the printer likes them more. Is there any other format which is even more faster? (Giff or anything else?) Thanks in advance!!! *Adam * *Using FOP 1.0* __ Information from ESET NOD32 Antivirus, version of virus signature database 5363 (20100813) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org Jeremias Maerki - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 5364 (20100813) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
How to prevent line break when hyphenation is enabled?
Hi, is there a way to prevent a line break inside a word, when hyphenation is enabled? I've tried two things, but neither of them did the trick: 1. Insert WORD JOINER characters (Ux2060) between all characters of the word 2. fo:inline keep-together.within-line=always/ I'm attaching a sample fo file, in case somebody wants to give it a try. Thanks Regards, Matthias Reischenbacher ?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; hyphenate=true language=de fo:layout-master-set fo:simple-page-master master-name=A4 page-height=29.7cm page-width=21cm margin=2cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body font-family=Helvetica fo:blockDer Bus Controller ermöglicht die Kopplung von XXX Link I/O Knoten an C#x2060;A#x2060;N#x2060;o#x2060;p#x2060;e#x2060;n. Der Bus Controller verfügt über./fo:block fo:blockDer Bus Controller ermöglicht die Kopplung von XXX Link I/O Knoten an C#8288;A#8288;N#8288;o#8288;p#8288;e#8288;n. Der Bus Controller verfügt über./fo:block fo:blockDer Bus Controller ermöglicht die Kopplung von XXX Link I/O Knoten an fo:inline keep-together.within-line=alwaysCANopen/fo:inline. Der Bus Controller verfügt über./fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Incorrect hyphenation of Polish language
Hi, I'm having problems with hyphenation of text in polish language. A polish translator checked a 200 pages PDF file generated by FOP and found over 30 hyphenation errors. I double checked if the language attribute was correctly set on the fo:root element. Is it possible that the hyphenation pattern is just wrong in some cases? If that's the case, are there any other hyphenation patterns that can be used (including commercial ones)? I attached a screenshot of one hyphenation error. I can also create a sample fo file containing all errors if it helps. Thanks Regards, Matthias Reischenbacher attachment: polish_hyphenation_error_screenshot.png - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to prevent line break when hyphenation is enabled?
Hi Simon, Any non-word character prevents hyphenation. Word characters are defined in the classes element in the source hyphenation file. For German these are a-z, ä, å, ö, ü and ß. WORD JOINER is not one of them, but apparently it is filtered out. I tried ZERO WIDTH JOINER, but that is rendered as an 'unknown glyph' #. Thanks for pointing into this direction. Using the ZERO WIDTH JOINER prevents hyphenation. I had to use Arial Unicode MS font in order to not get the unknown glyph error. What is kind of strange although, when using some other font, which also contains this character (e.g. Arial, Calibri, Times New Roman etc. [1]), the character gets displayed in a weird way (have a look at the attached screenshot). I'd prefer to use Arial because it's a Windows standard font, but if that's not possible I'm happy with the current solution too. Which part of the FOP code is responsible for drawing this character in PDF output? [1] http://www.fileformat.info/info/unicode/char/200d/fontsupport.htm Regards, Matthias attachment: arial_zero_width_joiner.png - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Incorrect hyphenation of Polish language
Hi, thanks for testing Pascal. Actually I was already using the new unicode hyphenation patterns (which by the way seem to work just fine in other languages). I think that the polish tex file is the same for both versions (The last modification date of the file is back in 1995!). http://www.ctan.org/tex-archive/language/hyphenation/ Are there any alternative hyphenation patterns? Regards, Matthias On 10.09.2010 09:47, Pascal Sancho wrote: Hi, I tried both OFFO 1.2 and utf-8 0.1 with a copy of the text nested in the Matthiass PNG, and I get the same output as described. So, I guess there is no change for the Polish between the 2 versions -- Pascal Le 10/09/2010 14:42, Simon Pepping a écrit : On Thu, Sep 09, 2010 at 07:08:45PM -0300, Matthias Reischenbacher wrote: Hi, I'm having problems with hyphenation of text in polish language. A polish translator checked a 200 pages PDF file generated by FOP and found over 30 hyphenation errors. I double checked if the language attribute was correctly set on the fo:root element. Is it possible that the hyphenation pattern is just wrong in some cases? If that's the case, are there any other hyphenation patterns Yes, that is possible. that can be used (including commercial ones)? At http://sourceforge.net/projects/offo/files/offo-hyphenation-utf8/0.1/offo-hyphenation-fop-stable-utf8.zip/download you will find some new hyphenation patterns, which you can try. They are based on the current UTF-8 hyphenation patterns in TeX. I do not know if the Polish patterns are really different from the old ones. You need fop-1.0 to use these patterns. Simon - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 5439 (20100910) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: Incorrect hyphenation of Polish language
Hi Georg, thanks for your response. In this case I don't want to prevent hyphenation. The problem is, that the hyphenation is done incorrectly. I might end up adding some exceptions in order to disable hyphenation for some words but that's only a suboptimal solution. Regards, Matthias On 10.09.2010 12:44, Georg Datterl wrote: Hi Matthias, I don't quite understand why keep-together does not work for you, but if you only have a few words where you want to prevent hyphenation, you can write exceptions directly into the pattern file. Mit freundlichen Grüßen Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Matthias Reischenbacher [mailto:matthias8...@gmx.at] Gesendet: Freitag, 10. September 2010 17:31 An: fop-users@xmlgraphics.apache.org Betreff: Re: Incorrect hyphenation of Polish language Hi, thanks for testing Pascal. Actually I was already using the new unicode hyphenation patterns (which by the way seem to work just fine in other languages). I think that the polish tex file is the same for both versions (The last modification date of the file is back in 1995!). http://www.ctan.org/tex-archive/language/hyphenation/ Are there any alternative hyphenation patterns? Regards, Matthias On 10.09.2010 09:47, Pascal Sancho wrote: Hi, I tried both OFFO 1.2 and utf-8 0.1 with a copy of the text nested in the Matthiass PNG, and I get the same output as described. So, I guess there is no change for the Polish between the 2 versions -- Pascal Le 10/09/2010 14:42, Simon Pepping a écrit : On Thu, Sep 09, 2010 at 07:08:45PM -0300, Matthias Reischenbacher wrote: Hi, I'm having problems with hyphenation of text in polish language. A polish translator checked a 200 pages PDF file generated by FOP and found over 30 hyphenation errors. I double checked if the language attribute was correctly set on the fo:root element. Is it possible that the hyphenation pattern is just wrong in some cases? If that's the case, are there any other hyphenation patterns Yes, that is possible. that can be used (including commercial ones)? At http://sourceforge.net/projects/offo/files/offo-hyphenation-utf8/0.1/offo-hyphenation-fop-stable-utf8.zip/download you will find some new hyphenation patterns, which you can try. They are based on the current UTF-8 hyphenation patterns in TeX. I do not know if the Polish patterns are really different from the old ones. You need fop-1.0 to use these patterns. Simon - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 5439 (20100910) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 5440 (20100910) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: Incorrect hyphenation of Polish language
Hi Simon, Can you not use discretionary hyphens in your fo file? No, that's not possible because the translator only gets a XML file for translation and has no idea where the line breaks will occur. I think you would have to take the source XML hyphenation pattern file, and edit that. Then remove the compiled hyp file from the jar and add the edited source file. You can also compile the source file (for efficiency); there is an ant task for it. The only other hyphenation patterns I know are those of OpenOffice. They are often also derived from the TeX patterns, but not always. I do not know how to use the OOo patterns in FOP or convert them to FOP. Apparently OpenOffice also uses the tex hyphenation patterns: http://extensions.services.openoffice.org/en/project/pl-dict http://wiki.services.openoffice.org/wiki/Documentation/SL/Using_TeX_hyphenation_patterns_in_OpenOffice.org But OpenOffice correctly hyphenates my sample text (Gwarantowany poziom emisji hałasu jest podany w Danych technicznych). I'm starting to think that the original polish tex hyphenation pattern might be just fine and that there could be some problem during conversion to the FOP hyphenation pattern. Or maybe FOP doesn't correctly use the pattern. What do you think? Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to prevent line break when hyphenation is enabled?
Hi, just in case somebody else has this problem: I ended up wrapping every single character inside a fo:character element and set the hyphenate attribute to false. This also prevents hyphenation and doesn't require the Arial Unicode MS font. e.g. fo:character hyphenate=false character=C/ fo:character hyphenate=false character=A/ fo:character hyphenate=false character=N/ fo:character hyphenate=false character=o/ fo:character hyphenate=false character=p/ fo:character hyphenate=false character=e/ fo:character hyphenate=false character=n/ I'm still wondering why XSL-FO doesn't allow the hyphenate attribute on fo:inline elements Regards, Matthias Reischenbacher On 10.09.2010 12:09, Matthias Reischenbacher wrote: Hi Simon, Any non-word character prevents hyphenation. Word characters are defined in the classes element in the source hyphenation file. For German these are a-z, ä, å, ö, ü and ß. WORD JOINER is not one of them, but apparently it is filtered out. I tried ZERO WIDTH JOINER, but that is rendered as an 'unknown glyph' #. Thanks for pointing into this direction. Using the ZERO WIDTH JOINER prevents hyphenation. I had to use Arial Unicode MS font in order to not get the unknown glyph error. What is kind of strange although, when using some other font, which also contains this character (e.g. Arial, Calibri, Times New Roman etc. [1]), the character gets displayed in a weird way (have a look at the attached screenshot). I'd prefer to use Arial because it's a Windows standard font, but if that's not possible I'm happy with the current solution too. Which part of the FOP code is responsible for drawing this character in PDF output? [1] http://www.fileformat.info/info/unicode/char/200d/fontsupport.htm Regards, Matthias __ Information from ESET NOD32 Antivirus, version of virus signature database 5440 (20100910) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org __ Information from ESET NOD32 Antivirus, version of virus signature database 5440 (20100910) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Padding-left ignored inside repeating table header
Hi Vincent, I had a look at the code you pointed me to and I think I found a possible reason for the problem but I'm not sure how to fix it. When the addAreas() method of the InlineLayoutManager is called, this code line is executed: setTraits(areaCreated, lastPos == null || !isLast(lastPos)); For the first table header the areaCreated variable is correctly set to false and the left padding is being applied. But for the repeating table header the value is false and therefore padding isn't applied. So my questions are: 1. Is it correct that the same InlineLayoutManager instance is used for both table headers? 2. If using the same instance is ok, is there any way to know that a page/column break had occurred? Does the layout context provide a method for knowing this? Thanks for your help... Matthias Vincent Hennebert-2 wrote: Hi Matthias, On 02/11/10 00:22, Matthias Reischenbacher wrote: Hi Vincent, thanks for confirming... Here is the bugzilla entry: https://issues.apache.org/bugzilla/show_bug.cgi?id=50196 Could you please point me to the releated FOP classes, so I can give it an attempt to fix it on my own? I’m not too sure actually. I suppose I would look in org.apache.fop.layoutmgr.inline.InlineLayoutManager, especially the getNextKnuthElements method, and see how padding is handled. Then o.a.f.layoutmgr.table.TableContentLayoutManager that manages the contents of the table header and footer. Then the respective addAreas methods that create the area tree. Check what padding has become at that stage. I hope this helps, Vincent Thanks Best regards, Matthias Vincent Hennebert-2 wrote: Hi Matthias, This is a bug. Could you please file a bug report on Bugzilla: https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop Thanks, Vincent On 28/10/10 15:45, MatthiasR wrote: Hi, I have a problem when using padding-left on a fo:inline element inside a repeating table header. The padding-left value is ignored on the repeated table header on the next page. Test case: http://old.nabble.com/file/p30077409/bg_bug.fo bg_bug.fo PDF result file: http://old.nabble.com/file/p30077409/bg_bug.pdf bg_bug.pdf I'm aware that there are other ways to move the text to the right but it would be nice if somebody can give me some feedback if this should be considered a bug. Thanks for your help Regards, Matthias Reischenbacher - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://old.nabble.com/Padding-left-ignored-inside-repeating-table-header-tp30077409p30202938.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Bug 49837 - Soft Hyphen
Hi Simon, wouldn't it be possible to partially undo the changes from this bugzilla entry: https://issues.apache.org/bugzilla/show_bug.cgi?id=48071 It's really hard to control that soft-hyphen characters are placed correctly when users can copy paste text into content (as in our CMS). Regards, Matthias Reischenbacher Simon Pepping @ Home wrote: On Thu, Dec 02, 2010 at 07:12:08PM +0200, Klearchos Klearchou wrote: I have Fop version 0.95 and I am trying to upgrade to 1.0 but I have problems with the following regression bug (49837 https://issues.apache.org/bugzilla/show_bug.cgi?id=49837 ). Is there any workaround for this? The problem occurs when a soft-hyphen follows white-space or is the first character in a block. You can work around it by avoiding those situations. If you encounter the problem in other situations, please, let us know. Simon - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://old.nabble.com/Bug-49837---Soft-Hyphen-tp30360601p30366538.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Complex Script, BIDI text supported?
Glenn, I tried your work today of the complex script branch. I managed to generate a PDF file with Hebrew text using Arial Unicode MS font and writing-mode set to rl-tb. The Hebrew text is displayed fine but english characters are also mirrored. Do I have to set an additional xsl-fo attribute in order to correctly display english characters or is the BIDI text algorithm not yet implemented? Thanks for your help, Matthias Reischenbacher -- View this message in context: http://old.nabble.com/Complex-Script%2C-BIDI-text-supported--tp31109094p31109094.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Complex Script, BIDI text supported?
Glenn, here it goes: Fo file: http://old.nabble.com/file/p31109566/hebrew_test.xml hebrew_test.xml PDF file: http://old.nabble.com/file/p31109566/hebrew_test.pdf hebrew_test.pdf Should I try building your code on git hub? I've never used git therefore I first went with the apache SVN branch. Thanks Regards, Matthias Glenn Adams-2 wrote: Matthias, Thanks for the report. Could you send me the FO input file and PDF output file? I am actively testing and fixing the Bidi and Script support, with real-time updates occurring at git://github.com/skynavga/fop.git. Regards, Glenn On Wed, Mar 9, 2011 at 11:28 AM, Matthias Reischenbacher matthias8...@gmx.at wrote: Glenn, I tried your work today of the complex script branch. I managed to generate a PDF file with Hebrew text using Arial Unicode MS font and writing-mode set to rl-tb. The Hebrew text is displayed fine but english characters are also mirrored. Do I have to set an additional xsl-fo attribute in order to correctly display english characters or is the BIDI text algorithm not yet implemented? Thanks for your help, Matthias Reischenbacher -- View this message in context: http://old.nabble.com/Complex-Script%2C-BIDI-text-supported--tp31109094p31109094.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://old.nabble.com/Complex-Script%2C-BIDI-text-supported--tp31109094p31109566.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Complex Script, BIDI text supported?
Ok, thanks a lot for your help! Matthias Glenn Adams-2 wrote: It appears the problem is due to a bug related to the use of block-container, which I will look into. However, if you remove block-container, and put the writing-mode and (default) font-family on fo:page-sequence, it should produce correct results. See attached for what I'm getting (using the current GITHUB repo) with a modified FO. I would advise you use the GIT repository for now, because it is kept up to date with my working copy. I submit a patch irregularly for integration into the SVN Temp_ComplexScripts branch. G. On Wed, Mar 9, 2011 at 12:21 PM, Matthias Reischenbacher matthias8...@gmx.at wrote: Glenn, here it goes: Fo file: http://old.nabble.com/file/p31109566/hebrew_test.xml hebrew_test.xml PDF file: http://old.nabble.com/file/p31109566/hebrew_test.pdf hebrew_test.pdf Should I try building your code on git hub? I've never used git therefore I first went with the apache SVN branch. Thanks Regards, Matthias Glenn Adams-2 wrote: Matthias, Thanks for the report. Could you send me the FO input file and PDF output file? I am actively testing and fixing the Bidi and Script support, with real-time updates occurring at git://github.com/skynavga/fop.git. Regards, Glenn On Wed, Mar 9, 2011 at 11:28 AM, Matthias Reischenbacher matthias8...@gmx.at wrote: Glenn, I tried your work today of the complex script branch. I managed to generate a PDF file with Hebrew text using Arial Unicode MS font and writing-mode set to rl-tb. The Hebrew text is displayed fine but english characters are also mirrored. Do I have to set an additional xsl-fo attribute in order to correctly display english characters or is the BIDI text algorithm not yet implemented? Thanks for your help, Matthias Reischenbacher -- View this message in context: http://old.nabble.com/Complex-Script%2C-BIDI-text-supported--tp31109094p31109094.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://old.nabble.com/Complex-Script%2C-BIDI-text-supported--tp31109094p31109566.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=simple page-height=5in page-width=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=simple writing-mode=rl-tb font-family=Arial Unicode MS fo:flow flow-name=xsl-region-body fo:blockחוברת הוראות בטיחות זו מתמקדת בכמה מהמצבים העקרוניים שעשויים להתרחש בעת הפעלת המכונה ותחזוקתה./fo:block fo:blockTest/fo:block /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://old.nabble.com/Complex-Script%2C-BIDI-text-supported--tp31109094p31110436.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: attaching a zip file in PDF
Neeraj,
I think the PDF attachment feature was added after the 1.0 release. You
might want to try a nightly snapshot:
http://ci.apache.org/projects/xmlgraphics/fop/snapshots/
HTH,
Matthias
nmquery wrote:
Hi,
I am not able to attach a zip file in PDF.
Message on console -
WARNING: Unknown formatting object
{http://xmlgraphics.apache.org/fop/extensions/pdf}embedded-file;
encountered (a child of fo:declarations}. (No context info available)
I am using Apache FOP 1.0. I tried 0.95 as well.
Please check xsl code below.
Can you please suggest why its not attaching the zip in PDF?
Thanks.
Regards
Neeraj
?xml version=1.0 encoding=UTF-8?
xsl:stylesheet version=1.1
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fo=http://www.w3.org/1999/XSL/Format; exclude-result-prefixes=fo
xsl:output method=xml version=1.0 omit-xml-declaration=no
indent=yes/
xsl:template match=OriginalNotification
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
xmlns:pdf=http://xmlgraphics.apache.org/fop/extensions/pdf;
fo:layout-master-set
fo:simple-page-master master-name=simpleA4
page-height=29.7cm page-width=21cm margin-top=1cm
margin-left=1.5cm margin-right=1.5cm margin-bottom=0.5cm
fo:region-body margin-bottom=1.5cm
margin-top=3cm/
/fo:simple-page-master
/fo:layout-master-set
fo:declarations
pdf:embedded-file filename=attachments.zip
src=url(file:///C:/attachments.zip) description=Attachments/
/fo:declarations
fo:page-sequence master-reference=simpleA4
fo:flow flow-name=xsl-region-body
fo:block
/fo:block
/fo:flow
/fo:page-sequence
/fo:root
!--
fo:basic-link
external-destination=url(file:///C:/attachments.zip)Attachments/fo:basic-link
--
/xsl:template
/xsl:stylesheet
--
View this message in context:
http://old.nabble.com/attaching-a-zip-file-in-PDF-tp31114498p31115152.html
Sent from the FOP - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Row span and keep-togehther.within-page problem
Hi, using the number-rows-spanned attribute on a table cell causes a page break in the middle of the table even though the fo:table element has the keep-together.within-page attribute set to always. If I remove the span attribute the page break goes away. Am I doing something wrong here or is this a bug? I'm using latest trunk version of FOP. Test case: http://old.nabble.com/file/p31169192/table-bug.xml table-bug.xml Output with span: http://old.nabble.com/file/p31169192/table-bug.pdf table-bug.pdf Output without span: http://old.nabble.com/file/p31169192/table-no-bug.pdf table-no-bug.pdf Best regards, Matthias Reischenbacher -- View this message in context: http://old.nabble.com/Row-span-and-keep-togehther.within-page-problem-tp31169192p31169192.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Row span and keep-togehther.within-page problem
Hi Andreas, thanks a lot for your explanation of how keep conditions are enforced! Today I had been looking at the same code as you and I found it odd that the table keep condition is only taken into account inside TableStepper.getCombinedKnuthElementsForRowGroup() if the rowFinished value is set to false. Do you have any idea what rowFinished means in this context? When debugging the code with my test case the value of rowFinished is always true and therefore the if statement seems to be dead code. Do you think it would be a solution to just move out lines 250 and 252 of the if statement and execute it always. Perhaps then the additional keep condition handling inside TableContentLM.getKnuthElementsForRowIterator() could be removed? Thanks Regards, Matthias Andreas Delmelle-2 wrote: On 18 Mar 2011, at 00:30, Matthias Reischenbacher wrote: snip / FWIW: I was just playing with the example, and noticed my suggestion --using keep.within-column-- does not help. This means, as Vincent suspects (IIC), that the culprit is the code that takes care of generating the element list in case of row-spanning cells, which inadvertently generates break-possibilities (i.e. does not take into account the keep that is dominating the ancestor fo:table) Comparing the case with and without row-span in a debug session reveals that, with row-span all BreakElements have penalty value 0, whereas without row-span, we get INFINITE, as expected. Looking deeper, in TableContentLM.getKnuthElementsForRowIterator(), notice that the case with row-span produces only one row-group, so the code that would set the keep constraint from the table --in the while loop, line 250-- never gets executed. The RowGroupLayoutManager gets passed a LayoutContext that is not properly initialized (keep=auto). Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- View this message in context: http://old.nabble.com/Row-span-and-keep-togehther.within-page-problem-tp31169192p31191188.html Sent from the FOP - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Complex Script, BIDI text supported?
Hi Glenn, thanks again for your help and doing all those fixes. Today I've retested my sample file with the git branch and everything works fine now. I'll do some more testing in the next weeks and I'll let you know if I encounter any problems. Are you planning to submit a new patch for the apache svn repo anytime soon? If not, no problem. I'm just asking because I have some local modifications in my svn working copy which I'll have to apply manually to the git working copy. Thanks best regards, Matthias Glenn Adams-2 wrote: Matthias, I've fixed the fo:block-container problem as well as text-align and treatment of writing-mode on page regions. The fixes are present in my GIT repo I referred to earlier (and also include all trunk commits up to this point). To be a little more detailed: - the use of writing-mode=rl on simple-page-master now results in correct interpretation of region-start and region end; i.e., region-start is now on the right side of the page (with 0 reference orientation), and region-end is on the left side; - the erroneous (historical) mirroring around the y axis of viewports with writing-mode=rl, including those generated by region-* and block-container, has been removed; - both text-align and text-align-last now treat start and end as relative to the writing mode, e.g., text-align=start is on the right when writing-mode=rl, etc. - if no text-align is specified, then in a writing-mode=rl context correctly results in right (i.e., start) alignment, while in lr start is on left (assuming reference orientation of 0); I am aware of an existing problem with text-align=justify in RTL WM contexts, and expect a fix in a day or so. Let me know if you encounter any other bidi problems. Also, just as a reminder, a neutral character, e.g., FULL STOP '.', at the end of a paragraph in a block takes on the default direction of the block. So, if you have a block of English text with a period at the end and it appears in a RTL WM context, then the period will be placed at the left of the last line, not the right as one might expect. This is actually correct behavior, and is a side effect of the Unicode bidi algorithm. To deal with this, you can wrap the English text including the period with fo:bidi-override unicode-bidi=embed direction=ltrSentence(s) with a period at the end./fo:bidi-override. This will create a LTR embedding context in the outer RTL context of the block. In general, you can use the fo:bidi-override element to both create bidi embedding levels and also to override the directionality of text as would be computed by the Unicode bidi algorithm. G. On Wed, Mar 9, 2011 at 2:28 PM, Glenn Adams gl...@skynav.com wrote: I have a fix for the block-container issue as well, which I will commit shortly to my GIT repo. The problem was that earlier (pre complex script) code apparently assumed that right-to-left writing mode was handled by mirroring the CTM around the y axis, so it was setting the CTM incorrectly for the viewport area generated by block-container. In fact there is no relationship between WM and reference orientation (and thus CTM on viewport area). I'll let you know when I've made the commit. G. On Wed, Mar 9, 2011 at 2:10 PM, Matthias Reischenbacher matthias8...@gmx.at wrote: Ok, thanks a lot for your help! Matthias Glenn Adams-2 wrote: It appears the problem is due to a bug related to the use of block-container, which I will look into. However, if you remove block-container, and put the writing-mode and (default) font-family on fo:page-sequence, it should produce correct results. See attached for what I'm getting (using the current GITHUB repo) with a modified FO. I would advise you use the GIT repository for now, because it is kept up to date with my working copy. I submit a patch irregularly for integration into the SVN Temp_ComplexScripts branch. G. On Wed, Mar 9, 2011 at 12:21 PM, Matthias Reischenbacher matthias8...@gmx.at wrote: Glenn, here it goes: Fo file: http://old.nabble.com/file/p31109566/hebrew_test.xml hebrew_test.xml PDF file: http://old.nabble.com/file/p31109566/hebrew_test.pdf hebrew_test.pdf Should I try building your code on git hub? I've never used git therefore I first went with the apache SVN branch. Thanks Regards, Matthias Glenn Adams-2 wrote: Matthias, Thanks for the report. Could you send me the FO input file and PDF output file? I am actively testing and fixing the Bidi and Script support, with real-time updates occurring at git://github.com/skynavga/fop.git. Regards, Glenn On Wed, Mar 9, 2011 at 11:28 AM, Matthias Reischenbacher matthias8...@gmx.at wrote: Glenn, I tried your work today of the complex script branch. I managed to generate a PDF file with Hebrew text using Arial Unicode
Re: Complex Script, BIDI text supported?
Glenn, I just tested a little bit more and the following questions/problems came up: 1. Are table cells also supposed to flow from right to left in rl-tb writing-mode? 2. Shouldn't list-item labels be displayed on the right side? 3. fo:character seem to overlap in rl mode. I'm attaching a new test file and the current PDF output. Thanks, Matthias On 22.03.2011 18:27, Matthias Reischenbacher wrote: Hi Glenn, thanks again for your help and doing all those fixes. Today I've retested my sample file with the git branch and everything works fine now. I'll do some more testing in the next weeks and I'll let you know if I encounter any problems. Are you planning to submit a new patch for the apache svn repo anytime soon? If not, no problem. I'm just asking because I have some local modifications in my svn working copy which I'll have to apply manually to the git working copy. Thanks best regards, Matthias Glenn Adams-2 wrote: Matthias, I've fixed the fo:block-container problem as well as text-align and treatment of writing-mode on page regions. The fixes are present in my GIT repo I referred to earlier (and also include all trunk commits up to this point). To be a little more detailed: - the use of writing-mode=rl on simple-page-master now results in correct interpretation of region-start and region end; i.e., region-start is now on the right side of the page (with 0 reference orientation), and region-end is on the left side; - the erroneous (historical) mirroring around the y axis of viewports with writing-mode=rl, including those generated by region-* and block-container, has been removed; - both text-align and text-align-last now treat start and end as relative to the writing mode, e.g., text-align=start is on the right when writing-mode=rl, etc. - if no text-align is specified, then in a writing-mode=rl context correctly results in right (i.e., start) alignment, while in lr start is on left (assuming reference orientation of 0); I am aware of an existing problem with text-align=justify in RTL WM contexts, and expect a fix in a day or so. Let me know if you encounter any other bidi problems. Also, just as a reminder, a neutral character, e.g., FULL STOP '.', at the end of a paragraph in a block takes on the default direction of the block. So, if you have a block of English text with a period at the end and it appears in a RTL WM context, then the period will be placed at the left of the last line, not the right as one might expect. This is actually correct behavior, and is a side effect of the Unicode bidi algorithm. To deal with this, you can wrap the English text including the period withfo:bidi-override unicode-bidi=embed direction=ltrSentence(s) with a period at the end./fo:bidi-override. This will create a LTR embedding context in the outer RTL context of the block. In general, you can use the fo:bidi-override element to both create bidi embedding levels and also to override the directionality of text as would be computed by the Unicode bidi algorithm. G. On Wed, Mar 9, 2011 at 2:28 PM, Glenn Adamsgl...@skynav.com wrote: I have a fix for the block-container issue as well, which I will commit shortly to my GIT repo. The problem was that earlier (pre complex script) code apparently assumed that right-to-left writing mode was handled by mirroring the CTM around the y axis, so it was setting the CTM incorrectly for the viewport area generated by block-container. In fact there is no relationship between WM and reference orientation (and thus CTM on viewport area). I'll let you know when I've made the commit. G. On Wed, Mar 9, 2011 at 2:10 PM, Matthias Reischenbacher matthias8...@gmx.at wrote: Ok, thanks a lot for your help! Matthias Glenn Adams-2 wrote: It appears the problem is due to a bug related to the use of block-container, which I will look into. However, if you remove block-container, and put the writing-mode and (default) font-family on fo:page-sequence, it should produce correct results. See attached for what I'm getting (using the current GITHUB repo) with a modified FO. I would advise you use the GIT repository for now, because it is kept up to date with my working copy. I submit a patch irregularly for integration into the SVN Temp_ComplexScripts branch. G. On Wed, Mar 9, 2011 at 12:21 PM, Matthias Reischenbacher matthias8...@gmx.at wrote: Glenn, here it goes: Fo file: http://old.nabble.com/file/p31109566/hebrew_test.xml hebrew_test.xml PDF file: http://old.nabble.com/file/p31109566/hebrew_test.pdf hebrew_test.pdf Should I try building your code on git hub? I've never used git therefore I first went with the apache SVN branch. Thanks Regards, Matthias Glenn Adams-2 wrote: Matthias, Thanks for the report. Could you send me the FO input file and PDF output file? I am actively testing and fixing the Bidi and Script support, with real-time updates occurring at git://github.com
Re: Problem with displaying crop marks
Hi Mario, you might check out Jeremias' example file: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/fo/advanced/bleed-and-crop-marks.fo?view=markuppathrev=800143 Regards, Matthias On 31.03.2011 12:00, Mario Madunic wrote: Using FOP 1.0 I've been trying to get crop marks to appear on a page by using the following extensions on simple-page-master with no luck !-- fox:bleed=.375in .3125in -- fox:crop-offset=2.375in 2.3125in fox:crop-box=trim-box I've played with various values and when cop-box is set to trim-box the page displayed is the actual page size (3.875w x 6.25h) without the added crop-offset. Can someone please give an example of how to use these extensions to add crop or trim marks. Thanks Marijan (Mario) Madunic Publishing Specialist New Flyer Industries Please consider the environment before printing this e-mail. CONFIDENTIALITY STATEMENT: This communication (and any and all information or material transmitted with this communication) is confidential, may be privileged and is intended only for the use of the intended recipient. If you are not the intended recipient, any review, retransmission, circulation, distribution, reproduction, conversion to hard copy, copying or other use of this communication, information or material is strictly prohibited and may be illegal. If you received this communication in error or if it is forwarded to you without the express authorization of New Flyer, please notify us immediately by telephone or by return email and permanently delete the communication, information and material from any computer, disk drive, diskette or other storage device or media. Thank you. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Complex Script, BIDI text supported?
Hi Glenn, thanks for your status update! I will test your changes in the next fiew days. I'll need support for fo:leaders, so thanks for taking care of that too. Best regards, Matthias On 31.03.2011 00:43, Glenn Adams wrote: Matthias, I just updated my working repo git://github.com/skynavga/fop.git with fixes for fo:table and fo:list-block to account for RTL writing modes; i.e., table column progression and list-item (label and body) alignment are now RTL in RTL WM contexts. In the process, I uncovered two other issues as well, which I am now working on along with the fo:character problem you reported: * fo:block-container does not align right in a RTL WM context when it does not use absolute or fixed positioning; * fo:leader is not working in a RTL WM context; I will update you when I have fixes committed for these issues. G. On Wed, Mar 23, 2011 at 6:45 AM, Glenn Adams gl...@skynav.com mailto:gl...@skynav.com wrote: Thanks for uncovering these issues. Let me address them and I'll let you know when they are fixed in my GIT repo. Perhaps after that I can submit a new patch update for the SVN branch. G. 2011/3/23 Matthias Reischenbacher matthias8...@gmx.at mailto:matthias8...@gmx.at Glenn, I just tested a little bit more and the following questions/problems came up: 1. Are table cells also supposed to flow from right to left in rl-tb writing-mode? 2. Shouldn't list-item labels be displayed on the right side? 3. fo:character seem to overlap in rl mode. I'm attaching a new test file and the current PDF output. Thanks, Matthias On 22.03.2011 18:27, Matthias Reischenbacher wrote: Hi Glenn, thanks again for your help and doing all those fixes. Today I've retested my sample file with the git branch and everything works fine now. I'll do some more testing in the next weeks and I'll let you know if I encounter any problems. Are you planning to submit a new patch for the apache svn repo anytime soon? If not, no problem. I'm just asking because I have some local modifications in my svn working copy which I'll have to apply manually to the git working copy. Thanks best regards, Matthias Glenn Adams-2 wrote: Matthias, I've fixed the fo:block-container problem as well as text-align and treatment of writing-mode on page regions. The fixes are present in my GIT repo I referred to earlier (and also include all trunk commits up to this point). To be a little more detailed: - the use of writing-mode=rl on simple-page-master now results in correct interpretation of region-start and region end; i.e., region-start is now on the right side of the page (with 0 reference orientation), and region-end is on the left side; - the erroneous (historical) mirroring around the y axis of viewports with writing-mode=rl, including those generated by region-* and block-container, has been removed; - both text-align and text-align-last now treat start and end as relative to the writing mode, e.g., text-align=start is on the right when writing-mode=rl, etc. - if no text-align is specified, then in a writing-mode=rl context correctly results in right (i.e., start) alignment, while in lr start is on left (assuming reference orientation of 0); I am aware of an existing problem with text-align=justify in RTL WM contexts, and expect a fix in a day or so. Let me know if you encounter any other bidi problems. Also, just as a reminder, a neutral character, e.g., FULL STOP '.', at the end of a paragraph in a block takes on the default direction of the block. So, if you have a block of English text with a period at the end and it appears in a RTL WM context, then the period will be placed at the left of the last line, not the right as one might expect. This is actually correct behavior, and is a side effect
Re: keep-together.within-line=always not working with inline and hyphenation
Hi Tobias,
a possible workaround for this bug is to wrap every text character in a
fo:character element and set its hyphenate attribute to false.
Here is a XSL example for doing that:
xsl:template match=text() mode=join
xsl:call-template name=doJoin
xsl:with-param name=text select=string(.)/
/xsl:call-template
/xsl:template
xsl:template name=doJoin
xsl:param name=text/
xsl:choose
xsl:when test=string-length($text) gt; 0
xsl:variable name=char select=substring($text, 1, 1)/
fo:character character={$char} hyphenate=false/
xsl:call-template name=doJoin
xsl:with-param name=text select=substring($text, 2)/
/xsl:call-template
/xsl:when
xsl:otherwise
xsl:value-of select=$text/
/xsl:otherwise
/xsl:choose
/xsl:template
I'd also advice to use latest trunk because 1.0 has a bug which causes a
NullPointerException when a white-space fo:character element is used as
the first element inside a fo:block. See also:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50988
HTH,
Matthias
On 14.04.2011 10:14, Tobias Rettstadt wrote:
Hi FOP experts,
I hope you can help me with my problem.
As I understand from the specification and previous posts, an inline with
keep-together.within-line=always should prevent hyphenation of the
containing text by ensuring that it is rendered on the same line. But that
does not seem to work in my case:
http://old.nabble.com/file/p31396866/test.fo test.fo
http://old.nabble.com/file/p31396866/test.pdf test.pdf
The word hyphenation is hyphenated despite the keep-together attribute. The
results can be reproduced with version 1.0 and the trunk version. The
following hyphenation patterns were used:
http://sourceforge.net/projects/offo/
Did I miss something or is this a bug in FOP for which I should file a bug
reports?
Thanks in advance,
Tobias
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Text fill color in external SVG is not preserved
Hi Jan, I use external graphics (SVG) in my FO document and when it is processed with FOP, color definition of some texts is ignored (they are black in the output). I can see the correct result in common browsers as well as in the Batik Squiggle utility. I think it is somehow connected to the transformation. Especially it happens at third sibling of the same group. Reduced SVG test case with FO file and final FOP output can be found at http://hroska.cz/other/test_case_fill.zip I use Fop - nightly build on Win7/64 bit + Java 6. All the a, b, c, d labels should be red (first two are red, the rest is black) All the Text (1, 2, 3) should be white (first two are white, the third is black) I believe this issue is caused by the commit of rev 1095887. I've already reported to the commiter (Jeremias) which, I think, is working on a fix. But you might want to create a bugzilla entry anyway as Andreas suggested. Is there any workaround? If you are familiar with svn und building FOP, you can locally undo the change from the mentioned revision and just re-build FOP. Best regards, Matthias Reischenbacher - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: PDF encryption and PDF image extension
As stated in my original message, I'm embedding other images in PDF format with the PDF image extension. So the mentioned example fo file doesn't show my issue because no PDF images are used there. Thanks anyway for your response, Matthias On 16.11.2011 20:32, Luis Bernardo wrote: The examples/fo/basic/images.fo example works well if you add -noprint to fop. That is: cd examples/fo/basic fop -noprint -fo images.fo -pdf images-noprint.pdf The end result shows the images and has Print disabled. So I don't think it is a FOP issue Luis On 11/16/11 7:12 PM, Matthias Reischenbacher wrote: Hi, when generating a PDF file with any of the PDF encryption parameters (noprint, nocopy etc.) PDF images (loaded by Jeremias' PDF image extension) are not displayed. Is this a limitation of the plugin or perhaps PDFbox or am I doing something wrong? See also the attached PDF files showing the issue. Thanks, Matthias - To unsubscribe, e-mail:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail:fop-users-h...@xmlgraphics.apache.org
Re: PDF encryption and PDF image extension
Hi, thanks for pointing that out. I'll try to use PDFbox directly for encryption to workaround this problem. Thanks for your help! Matthias On 17.11.2011 21:25, Luis Bernardo wrote: The issue with PDF images was discussed in the past. See http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-users/200812.mbox/browser. It still exists. If you run fop with a file that uses a pdf image as an external graphic you should see the warning WARNING: DCTFilter.decode is not implemented yet, skipping this stream if you pass the -noprint switch. There is no such warning if no -noprint switch is used. I believe the warning correctly identifies the problem. Luis On 11/17/11 2:33 AM, Matthias Reischenbacher wrote: As stated in my original message, I'm embedding other images in PDF format with the PDF image extension. So the mentioned example fo file doesn't show my issue because no PDF images are used there. Thanks anyway for your response, Matthias On 16.11.2011 20:32, Luis Bernardo wrote: The examples/fo/basic/images.fo example works well if you add -noprint to fop. That is: cd examples/fo/basic fop -noprint -fo images.fo -pdf images-noprint.pdf The end result shows the images and has Print disabled. So I don't think it is a FOP issue Luis On 11/16/11 7:12 PM, Matthias Reischenbacher wrote: Hi, when generating a PDF file with any of the PDF encryption parameters (noprint, nocopy etc.) PDF images (loaded by Jeremias' PDF image extension) are not displayed. Is this a limitation of the plugin or perhaps PDFbox or am I doing something wrong? See also the attached PDF files showing the issue. Thanks, Matthias - To unsubscribe, e-mail:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail:fop-users-h...@xmlgraphics.apache.org
Footnotes order tables
Hi, as suggested by existing threads in this list I generate footnote reference numbers with XSL. See also: http://apache-fop.1065347.n5.nabble.com/Footnote-question-td7255.html This works perfectly for normal text, but now I have a new case where footnotes are inside table cells and the processing sequence of FOP doesn't match the one of XSL. Internally FOP seems to process table cell contents by line, going from left to right (across multiple cells). XSL on the other hand processes the first cell completely and then the next cell and so on. The output is that the ordering of the footnote bodies in the footer isn't the one expected by the user. See also the attached examples (fo + pdf): Footnote 3 is second but should be third. I understand that the processing has to be done like that, especially if a page break occurs inside the table cell. Footnotes at the bottom of a table cell would be pushed to the next page, making the resulting footnote body order ok again. What I would like to do is to (optionally) modify the processing order in FOP in case a keep condition is defined for the table row. Has anybody tried to do something similar? Could anybody of the table/footnote gurus please point me in the right direction? Btw... Too bad that xsl fo doesn't define an element for a truly automatic footnote numbering (similar to Antenna House's axf:footnote-number/). Is it part of xsl fo 2.0? Best regards, Matthias Reischenbacher ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=normal page-width=210mm page-height=297mm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:static-content flow-name=xsl-footnote-separator fo:block border-top=solid 5pt red/ /fo:static-content fo:flow flow-name=xsl-region-body fo:table table-layout=fixed width=100% fo:table-body fo:table-row fo:table-cell fo:blockline1/fo:block fo:blockline2fo:footnote fo:inline font-size=70% baseline-shift=super1/fo:inline fo:footnote-body fo:block background-color=orangeFootnote 1/fo:block /fo:footnote-body /fo:footnote /fo:block fo:blockline3/fo:block fo:blockline4/fo:block fo:block line5fo:footnote fo:inline font-size=70% baseline-shift=super2/fo:inline fo:footnote-body fo:block background-color=orangeFootnote 2/fo:block /fo:footnote-body /fo:footnote /fo:block /fo:table-cell fo:table-cell fo:blockline1/fo:block fo:block line2fo:footnote fo:inline font-size=70% baseline-shift=super3/fo:inline fo:footnote-body fo:block background-color=orangeFootnote 3/fo:block /fo:footnote-body /fo:footnote /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root footnote-order.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Upgrade to fop trunk and URI resolving
Hi, I just tried to upgrade to latest trunk and noticed two compatibility issues with my application which I couldn't fix on my own: * The fontManager has no setBaseURL method anymore. How is the base URL set now? * The FOURIResolver class doesn't exist anymore. Sub classing it for applying HTTP basic authentication parameters is therefore not possible. See also: http://wiki.apache.org/xmlgraphics-fop/HowTo/BasicHttpAuthentication How is HTTP authentication handled now? Thanks for your help, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Upgrade to fop trunk and URI resolving
Hi Mehdi, thanks for your explanation. Some questions: 1. What's the default font base directory? The same as the normal base directory? 2. Can I use a path relative to the normal base directory for the font base directory? 3. Back to URI resolving: I'm a bit afraid of breaking something if I implement my own URI resolver. What does the default resolver do? It would be nice if the default resolver would be part of the public API so that I can sub class it and just inject the authentication params (like before). Btw... it's really nice that all data is loaded now through the new URI resolver. In the near future I'd like to use a custom scheme (e.g. myscheme://imageid) in order to load images instead of using HTTP. That wouldn't be possible without your change. So thanks! Best regards, Matthias On 24.07.2012 04:23, mehdi houshmand wrote: Sorry Matthias, I'm an idiot. Not defining a font-base wasn't an over sight at all; I was just implementing a font-base injection mechanism and I remembered why we didn't allow this programmatically. You have to define the font-base using the font-base element in the fop-conf, that's the only way to do it and it's intentional. I'll take this opportunity to explain why we've done what we've done for the sake of the community, if you're not interested feel free to ignore the next section: Some of the problems we were seeing when dealing with a lot of these configuration classes was that people were adding new parameters and functionality to them incrementally, as is the case with open-source. The problem was that there were several ways of doing the same thing and getters/setters all over the place. So what we did was try and ask what would a user want to do? And how do we make that as easy as possible while still maintaining some encapsulation and immutability in these classes? How does relate to the font-base? Well, it seems like an abuse of encapsulation to allow users to set the font-base-URI directly onto the FontManager. Users shouldn't need to care about these internal mechanisms, they should be able to just configure it and it works. So we decided to enforce a single parameter to set the font-base (font-base in the fop-conf) because th only reason someone would want to define a font-base-URI would be if they had custom fonts setup, and in order to do so they'd need a fop-conf anyways. So we might as well enforce a single point of entry for the font-base-URI, otherwise you'll have to do if (x != null) checks all over the place and how would you decide which parameter overrides which? Why should a programmatically set font-base override the one found in the font-base? How do we document this so that users it's abundantly obvious to users? We asked ourselves is there a use case for setting this programmatically rather than through the fop-conf? We couldn't see why anyone would want to do that. We have tried to reduce the number of entry points for injecting configuration parameters, for two reasons; 1) because it wasn't documented and certainly wasn't obvious which parameters overrode which, when two of the same config parameters were used; 2) for the sake of developers, so that once the FopFactory hand been created, its state is mostly immutable (it has mutable members) and we can make certain assertions on the immutability of the members. Hope that makes our intentions clear, Mehdi On 24 July 2012 07:35, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: Hi Matthias, The way we've implemented the interface, you can be completely in control of how HTTP is authenticated by implementing o.a.f.apps.io.ResourceResolver[1] and giving it to the FopFactoryBuilder/FopConfParser[2]. As for the base URI for fonts, you can set this in the fop-conf, we haven't created a way to set this programmatically, that was an oversight on our end. I'll enable a way to do this and get back to you. [1] http://wiki.apache.org/xmlgraphics-fop/URIResolution [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration Hope that helps, Mehdi On 24 July 2012 00:01, Matthias Reischenbacher matthias8...@gmx.at mailto:matthias8...@gmx.at wrote: Hi, I just tried to upgrade to latest trunk and noticed two compatibility issues with my application which I couldn't fix on my own: * The fontManager has no setBaseURL method anymore. How is the base URL set now? * The FOURIResolver class doesn't exist anymore. Sub classing it for applying HTTP basic authentication parameters is therefore not possible. See also: http://wiki.apache.org/__xmlgraphics-fop/HowTo/__BasicHttpAuthentication http://wiki.apache.org/xmlgraphics-fop/HowTo/BasicHttpAuthentication How is HTTP authentication handled now? Thanks for your help, Matthias
Re: Upgrade to fop trunk and URI resolving
Hi Mehdi,
thanks for updating the javadoc.
I've been experimenting with the new API and I've found a minor bug
about font configuration. Please have a look at the following piece of
code of the ParserHelper inside DefaultFontConfig:
private ParserHelper(Configuration cfg, boolean strict) throws
FOPException {
if (cfg == null || cfg.getChild(fonts, false) == null) {
instance = null;
} else {
this.strict = strict;
this.fontInfoCfg = cfg.getChild(fonts, false);
instance = new DefaultFontConfig(cfg.getChild(auto-detect,
false) != null);
parse();
}
}
The auto-detect element is not read from the this.fontInfoCfg element as
it should be. Could you please fix that?
Thanks,
Matthias
On 26.07.2012 11:03, mehdi houshmand wrote:
Hi Matthias,
I've added some javadocs that may help to enlighten devs about how to do
some of the URI schema features you were asking about. As a potential
user, if you could take a look and let me know whether it's clear
enough, I'd be very grateful. I always find hard to know how much
information to put in a javadoc...
Thanks
Mehdi
On 26 July 2012 08:48, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com wrote:
That was supposed to say RESOLVER FOR GIVEN SCHEMA.
On 26 July 2012 08:46, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com wrote:
Hi Matthias,
Don't be so quick to thank us for this work, you may retract
that once you start using it ;).
1. Good question. The way it works is that you give the
FopFactory (either in a constructor or via the
EnvironmentProfile) a base-URI, this will become the default
base URI should a font-base not be given.
2. Yes, you can use a relative URI and it resolves against the
default base URI described in 1). What I've tried to do is make
all URIs resolve to against single base URI that is given in the
constructor of the FopFactory. Interestingly though, I just
noticed something we didn't consider. What if the URI given to
the FopFactory isn't an absolute URI? We don't check at any
point to ensure it is absolute... I think it would resolve
against new URI(.) where-ever that may be. Maybe we want
throw an IllegalArgumentException? I don't know.
3. There is some documentation as to how to do this, though I
think we could have probably done better in publishing more
detailed explanation as to what we've done here. So we have
created a mechanism for handling URI schemes, since it's an
integral part of the URI spec, and it's almost the raison
d'etre. Look at the o.a.f.apps.io.ResourceResolverFactory and
its unit test (o.a.f.apps.io.ResourceResolverFactoryTestCase)
the static inner class
TestCreateSchemaAwareResourceResolverBuilderHelper (say that
quickly 20 times) does what you're looking for.
Essentially do the following:
ResourceResolverFactory.SchemaAwareResourceResolverBuilder
builder =
ResourceResolverFactory.createSchemaAwareResourceResolverBuilder(DEFAULT
RESOLVER);
builder.registerResourceResolverForSchema(SCHEMA, RESOLVER
GIVEN SCEHMA);
... // you can add any number of schemas with their
corresponding resolvers
ResourceResolver resolver = builder.build();
// resolver is then used as the resolver given to either the
FopFactoryBuilder or FopConfParser, either directly or via the
EnvironmentProfile.
I'd play around with this mechanism, it can be very powerful
once you play around with URIs. You can define the the font-base
as font:// and use font as the schema and thus have much
finer control as to where the fonts are. This brings the full
power of the URI spec to all resource acquisition. All you have
to do is implement the ResourceResolver interface.
Also, an FYI for you and anyone else that uses FOP in systems
that require fine-grained control over I/O and file access; you
can now control where FOP writes/reads from temporary files
(scratch files used to save on memory.) By implementing the
o.a.f.apps.io.TempResourceResolver, you can mitigate any
security risks from leaking information or any worries one may
have. (Though realistically, the way FOP uses scratch files,
that's not very likely, but it's always better safe than sorry.)
I hope all that makes sense, if not, please feel free to ask me
to clarify.
Mehdi
On 25 July 2012 21:25, Matthias Reischenbacher
matthias8...@gmx.at mailto:matthias8...@gmx.at wrote:
Hi Mehdi,
thanks for your explanation. Some questions:
1. What's the default font base directory? The same as the
normal
Re: Upgrade to fop trunk and URI resolving
Hi Mehdi,
ok, no problem. While you are at it, please also check why the font
cache file isn't re-generated automatically. Since there has been some
change regarding font loading an exception is thrown (sorry I have no
stack trace right now, but I think it is caused by LazyFont.fontEmbedURI
being null). Deleting the cache file, fixes this behavior.
Thanks,
Matthias
On 07.08.2012 04:04, mehdi houshmand wrote:
Hi Matthias
I haven't had a chance to look at this, I will do so in the next few
days. Sorry for the slow response, I will address this issue shortly.
Mehdi
On 2 August 2012 02:14, Matthias Reischenbacher matthias8...@gmx.at
mailto:matthias8...@gmx.at wrote:
Hi Mehdi,
thanks for updating the javadoc.
I've been experimenting with the new API and I've found a minor bug
about font configuration. Please have a look at the following piece
of code of the ParserHelper inside DefaultFontConfig:
private ParserHelper(Configuration cfg, boolean strict) throws
FOPException {
if (cfg == null || cfg.getChild(fonts, false) == null) {
instance = null;
} else {
this.strict = strict;
this.fontInfoCfg = cfg.getChild(fonts, false);
instance = new
DefaultFontConfig(cfg.__getChild(auto-detect, false) != null);
parse();
}
}
The auto-detect element is not read from the this.fontInfoCfg
element as it should be. Could you please fix that?
Thanks,
Matthias
On 26.07.2012 11 tel:26.07.2012%2011:03, mehdi houshmand wrote:
Hi Matthias,
I've added some javadocs that may help to enlighten devs about
how to do
some of the URI schema features you were asking about. As a
potential
user, if you could take a look and let me know whether it's clear
enough, I'd be very grateful. I always find hard to know how much
information to put in a javadoc...
Thanks
Mehdi
On 26 July 2012 08:48, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com
mailto:med1...@gmail.com mailto:med1...@gmail.com wrote:
That was supposed to say RESOLVER FOR GIVEN SCHEMA.
On 26 July 2012 08:46, mehdi houshmand med1...@gmail.com
mailto:med1...@gmail.com
mailto:med1...@gmail.com mailto:med1...@gmail.com wrote:
Hi Matthias,
Don't be so quick to thank us for this work, you may
retract
that once you start using it ;).
1. Good question. The way it works is that you give the
FopFactory (either in a constructor or via the
EnvironmentProfile) a base-URI, this will become the
default
base URI should a font-base not be given.
2. Yes, you can use a relative URI and it resolves
against the
default base URI described in 1). What I've tried to do
is make
all URIs resolve to against single base URI that is
given in the
constructor of the FopFactory. Interestingly though, I just
noticed something we didn't consider. What if the URI
given to
the FopFactory isn't an absolute URI? We don't check at any
point to ensure it is absolute... I think it would resolve
against new URI(.) where-ever that may be. Maybe we
want
throw an IllegalArgumentException? I don't know.
3. There is some documentation as to how to do this,
though I
think we could have probably done better in publishing more
detailed explanation as to what we've done here. So we have
created a mechanism for handling URI schemes, since it's an
integral part of the URI spec, and it's almost the raison
d'etre. Look at the o.a.f.apps.io
http://o.a.f.apps.io.__ResourceResolverFactory and
its unit test (o.a.f.apps.io
http://o.a.f.apps.io.__ResourceResolverFactoryTestCas__e)
the static inner class
__TestCreateSchemaAwareResourceR__esolverBuilderHelper (say that
quickly 20 times) does what you're looking for.
Essentially do the following:
ResourceResolverFactory.__SchemaAwareResourceResolverBui__lder
builder =
ResourceResolverFactory.__createSchemaAwareResourceResol__verBuilder(DEFAULT
RESOLVER);
builder.__registerResourceResolverForSch__ema(SCHEMA,
RESOLVER
GIVEN SCEHMA);
... // you can add any number of schemas with their
corresponding resolvers
ResourceResolver resolver = builder.build();
// resolver is then used
SVG text misplaced
Hi, one of my clients reported a strange problem with SVG text being misplaced in PDF output when very high font size values are used. The sample SVG file also uses very high viewBox values. I created a test case which reproduces the issue when increasing the font size from 2578pt to 2579pt: suddenly the characters are misaligned. The issue doesn't occur when outputting PNG or PS files, so perhaps this is only related to the PDF code. I've been debugging for several hours, but I can't find the cause. I'm attaching a fo file which reproduces the issue and the current PDF output. Perhaps someone can have a look at it and tell me which code part I should check, in order to fix the issue. Thanks for your help. Best regards, Matthias ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=Helvetica fo:layout-master-set fo:simple-page-master master-name=normal page-width=210mm page-height=297mm fo:region-body margin=2cm/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal fo:flow flow-name=xsl-region-body fo:block fo:instream-foreign-object width=100% content-width=scale-to-fit svg xmlns=http://www.w3.org/2000/svg; viewBox=0 0 65625 84375 version=1.1 g text style=font-size:2578pt;font-family:sans-serif; y=3312 x=0Maradona/text /g g text style=font-size:2579pt;font-family:sans-serif; y=6312 x=0Maradona/text /g /svg /fo:instream-foreign-object /fo:block /fo:flow /fo:page-sequence /fo:root svg-font-issue.pdf Description: Adobe PDF document - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: SVG text misplaced
Hi Mehdi, thanks a lot for having a closer look! You pointed me in the right direction and I managed to read the char width with the long data type and cast to int after the conversion back to pts. Since this is more a hack than a definitive fix, I'll don't create a patch for now. What do you think of converting all font size related variables from int to long? I didn't do so because a lot of code would have to be modified and I'm not sure how this would impact memory consumption. I'm not in full control of the SVG creation (files are exported from Corel Draw), that's the reason why the SVG file is a bit odd. Normally I don't use fo:instream-foreign-object/, that was only for providing a more compact test case. Thanks again for your help best regards, Matthias On 24.09.2012 06:14, mehdi houshmand wrote: Ok... This one's a tricksy little badger. Basically, because you're using a font-size that's so large (especially when you convert pts - mpts as FOP works in) we're basically seeing an integer-overflow issue: 2579 pts = 2579000 mpts 833mpts = width of M glyph in Helvetica In Java (read: 32-bit integers), try 2579000 * 833, the result is -2146660296, it should be 2148307000. This means when FOP attempts to draw the glyphs with the appropriate kerning, an erroneous value is being given as the glyph-width of the M character. I'm not really sure if this is a bug, there's always going to be a limitation on the size of the document FOP can produce because we have to work with integers that can overflow, if that limitation is 2147483648 / 1000 / 72 inches (or 29826 inches), I think we have enough scope there to feel assured that we're within the bounds of reasonable use. If you need any help changing your document to be a bit more FOP-friendly, please feel free to ask any further questions and I/we will try and help as much as we can. Hope that helps, Mehdi On 24 September 2012 09:38, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: Hi Matthias, I've just taken a quick look at this and I'm not really sure what you're attempting to do here. Why have you made the viewBox so large and then put scale to fit on the fo:instream-foreign-object? You can reduce the size of the view box such that you don't need to scale-to-fit the SVG image. Is there any reason why you're trying to use such large fonts sizes and drawing space? I'm going to look into why the kerning on that M is so far off, but you may be able to work around this issue. Thanks Mehdi On 24 September 2012 03:20, Matthias Reischenbacher matthias8...@gmx.at mailto:matthias8...@gmx.at wrote: Hi, one of my clients reported a strange problem with SVG text being misplaced in PDF output when very high font size values are used. The sample SVG file also uses very high viewBox values. I created a test case which reproduces the issue when increasing the font size from 2578pt to 2579pt: suddenly the characters are misaligned. The issue doesn't occur when outputting PNG or PS files, so perhaps this is only related to the PDF code. I've been debugging for several hours, but I can't find the cause. I'm attaching a fo file which reproduces the issue and the current PDF output. Perhaps someone can have a look at it and tell me which code part I should check, in order to fix the issue. Thanks for your help. Best regards, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Extract font width using FOP
Hi,
what you need is an instance of FontInfo, from there you can retrieve
the Font you need and call getCharWidth().
If you are using FOP version 1.1 or older use the following code snippet:
import org.apache.fop.apps.FOPException;
import org.apache.fop.fonts.EmbedFontInfo;
import org.apache.fop.fonts.FontCollection;
import org.apache.fop.fonts.FontEventListener;
import org.apache.fop.fonts.FontInfo;
import org.apache.fop.fonts.FontInfoConfigurator;
import org.apache.fop.fonts.FontManager;
import org.apache.fop.fonts.FontManagerConfigurator;
import org.apache.fop.fonts.FontResolver;
import org.apache.fop.fonts.FontSetup;
FontInfo fontInfo = new FontInfo();
FontResolver fontResolver = FontManager.createMinimalFontResolver();
FontManager fontManager = new FontManager();
final FontEventListener listener = null;
final boolean strict = false;
FontManagerConfigurator fm = new
FontManagerConfigurator(this.getConfiguration());
fm.configure(fontManager, true);
FontInfoConfigurator fontInfoConfigurator
= new FontInfoConfigurator(this.getConfiguration(), fontManager,
fontResolver, listener, strict);
ListEmbedFontInfo fontInfoList = new ArrayListEmbedFontInfo();
fontInfoConfigurator.configure(fontInfoList);
if (fontManager.useCache()) {
fontManager.getFontCache().save();
}
FontSetup.setup(fontInfo, fontInfoList, fontResolver);
fontManager.setup(fontInfo, new FontCollection[]{});
For the FOP trunk version the following code snippet has to be used:
import org.apache.fop.apps.FOPException;
import org.apache.fop.apps.FOUserAgent;
import org.apache.fop.apps.Fop;
import org.apache.fop.apps.FopConfParser;
import org.apache.fop.apps.FopFactory;
import org.apache.fop.apps.FopFactoryBuilder;
import org.apache.fop.apps.io.InternalResourceResolver;
import org.apache.fop.apps.io.Resource;
import org.apache.fop.apps.io.ResourceResolver;
import org.apache.fop.apps.io.ResourceResolverFactory;
import org.apache.fop.fonts.DefaultFontConfig;
import org.apache.fop.fonts.DefaultFontConfigurator;
import org.apache.fop.fonts.EmbedFontInfo;
import org.apache.fop.fonts.FontCacheManagerFactory;
import org.apache.fop.fonts.FontCollection;
import org.apache.fop.fonts.FontDetectorFactory;
import org.apache.fop.fonts.FontEventListener;
import org.apache.fop.fonts.FontInfo;
import org.apache.fop.fonts.FontManager;
import org.apache.fop.fonts.FontManagerConfigurator;
import org.apache.fop.fonts.FontSetup;
FontInfo fontInfo = new FontInfo();
final FontEventListener listener = null;
final boolean strict = false;
Configuration cfg = this.getConfiguration();
ResourceResolver resResolver =
ResourceResolverFactory.createDefaultResourceResolver();
InternalResourceResolver resourceResolver
=
ResourceResolverFactory.createDefaultInternalResourceResolver(this.getBaseURI());
FontManager fontManager = new FontManager(resourceResolver,
FontDetectorFactory.createDefault(),
FontCacheManagerFactory.createDefault());
FontManagerConfigurator fm = new FontManagerConfigurator(cfg,
this.getBaseURI(), resResolver);
fm.configure(fontManager, true);
DefaultFontConfig.DefaultFontConfigParser parser
= new DefaultFontConfig.DefaultFontConfigParser();
DefaultFontConfig fontInfoConfig = parser.parse(cfg, strict);
DefaultFontConfigurator fontInfoConfigurator
= new DefaultFontConfigurator(fontManager, listener, strict);
ListEmbedFontInfo fontInfoList =
fontInfoConfigurator.configure(fontInfoConfig);
fontManager.saveCache();
FontSetup.setup(fontInfo, fontInfoList, resourceResolver, false);
fontManager.setup(fontInfo, new FontCollection[]{});
return fontInfo;
Best regards,
Matthias
On 16.11.2012 15:23, cdellasanta wrote:
Hi all,
I'm trying to auto size a font to not exceed the block dimensions, giving a
default max size and downgrading to predefined steps until it fits or a
minimum size is reached.
I can't use the SVG trick because I want to fit to a max defined width,
and and as the size is reduced more text will fit in a single line.
My idea is to build an external processor step that calculates the optimum
font size to be used for the block. But to do this I need the exact font
width (in millipoints) of each character (or word) of the selected font
triplet on each font size I intend to use.
Browsing the fop project source I've found the
org.apache.fop.fonts.Font.getCharWidth(), but It's for me a bit tricky to
instantiate correctly this Class.
I assume the the best way to get this is to start from the
org.apache.fop.tools.fontlist.FontListMain that does already the fop
configuration and loading of the font. But as a xsl-fo end-user, I've no
knowledge on the fop internals (structure/architecture) to go from A to B.
Can you please give me some hints or practical examples?
Wold it make sense to extend the org.apache.fop.tools to provide this
functionality?
Or am I on the wrong way?
Thanks in advance for any hint or feedback you can provide.
Regards.
p.s. I'm generating documents using a
Re: Encryption and links
Hi Luis, I've had the same issue and created a jiira issue with a minimal test case, see: https://issues.apache.org/jira/browse/FOP-2279 The problem also exists in current trunk. Regarding Bouncy Castle: this is documented here: http://xmlgraphics.apache.org/fop/1.1/pdfencryption.html#install_crypto Is this not necessary anymore with newer JDKs? Best regards, Matthias On 23.07.2013 07:57, Luis Bernardo wrote: Why do you need to use Bouncy Castle? And can you provide an example of your source FO file? It is possible that the problem you see is also present in trunk. Note that support for encryption in trunk has been expanded since the the 1.0 release so you may want to try trunk too. On Tue, Jul 23, 2013 at 6:47 AM, lars.bjer...@swedbank.se mailto:lars.bjer...@swedbank.se wrote: Hi. I have been implementing the Bouncy Castle encryption support as described in the FOP docs and almost everything works out fine. What does not work however is the implementation of external links (fo:basic-link - external-destination). In my case the link target will be an Internet URL (e.g. http://x.y.com). When I try to click on a link in the resulting PDF I will be directed to my default browser but with a “Target not found” message. When inspecting the URL I find that it starts with file:///C:/eclipse.../out/ which is the path to the created PDF. After that there is just a string of hexadecimal characters (encrypted URL I suspect). However, when turning off encryption and not changing any other parameter, the links will work all right. I am currently using FOP 1.0 but looked at history of changes for 1.1 I did not see anything relating to this. I found some information regarding this on Internet from 2008 FOP 0.95 and so my questions are: Is the bug still there (it seems so)? Does anybody have a workaround (without hacking the FOP code)? Regards *Lars Bjerges* zOS Common Function(Sweden) Swedbank AB (publ) 105 34 Stockholm Telefon: +46 (0)8 58 59 43 45 tel:%2B46%20%280%298%C2%A058%2059%2043%2045 Mobil: +46 (0)70 95 27 774 tel:%2B46%20%280%2970%C2%A095%2027%20774 Email:lars.bjer...@swedbank.se www.swedbank.se Vi ber dig lägga märke till att detta e-postmeddelande kan innehålla konfidentiell information. Om du felaktigt blivit mottagare av detta meddelande ber vi dig informera avsändaren om felet genom att använda svara-funktionen. Vi ber dig också att radera e-postmeddelandet utan att skicka det vidare eller kopiera det. Trots att vi intygar att e-postmeddelandet och eventuella bilagor inte innehåller virus och andra fel som kan påverka datorn eller IT-systemet där det mottages och läses, öppnas det på mottagarens eget ansvar. Vi tar inte på oss något ansvar för förlust eller skada, som har uppstått i samband med att e-postmeddelandet mottagits och använts. _ Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachment are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.
Re: SVG - embedded CMYK bitmaps
Hi, I just realized that CMYK-Bitmaps inside SVGs are handled correctly with FOP/Batik. No conversion is done to RGB. I didn't check my sample image enough, which was already in RGB. Sorry for the noise. @Luis: I've successfully used JPEG-CMYKs with FOP in the past. TIFF-CMYK are more problematic so I'll give TwelveMonkeys a try if it comes up again. Regards, Matthias On 28.01.2014 18:09, Matthias Reischenbacher wrote: Hi, I've noticed that JPEGs with DeviceCMYK color space, embedded in SVGs, are converted to sRGB when generating a PDF file. Does that happen with all kind of JPEG CMYKs? How are embedded bitmaps processed? Is that done by Batik and that's way its handled differently than normal fo:external-graphic CMYK-JPEGs? Thanks for any clarification on this matter... I've attached a sample SVG file. Best regards, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Retrieve-Marker retrieve-position = all?
Hi, I'd like to display multiple markers with the same name on the page header. Conceptually those markers correspond to chapter titles and all chapter titles, visible on a single page, should be printed. Up until now I've used the retrieve-position attribute for showing the first or last chapter title. But this time I'd need the first, last and all in between on the current page. Is this even possible with XSL-FO/FOP? If not, is it achievable by manipulating the fop intermediate structure? Best regards, Matthias - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP 1.1 RTF Output empty
Hi, RTF support is a bit broken in 1.1, see also https://issues.apache.org/jira/browse/FOP-2182 You can workaround by not using a PageSequenceMaster, so use your simple page master's name first as master-reference on the fo:page-sequence element and it should process again without errors. Regards, Matthias On 20.05.2015 06:03, Marc Wiest wrote: I just tried to upgrade from FOP 1.0 to 1.1 and while most things work, one RTF document doesn't. It worked smoothly with the 1.0 version, but now produces an empty zero-byte OutputStream (ByteArrayOutputStream in my case). No errors in the log, nothing. The upgrade notes https://xmlgraphics.apache.org/fop/1.1/upgrading.html don't state anything about incompatibilities with RTF. Any idea? Attached are the xml, xsl and the working output from FOP 1.0. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: Question about Font selection
Hi Markus, just found the attached file as a starting point... Matthias On 21.05.2015 09:14, markus.sticker.e...@zf.com wrote: Hi Matthias, Maybe I can build a xsl template for that. B *Von:*Matthias Reischenbacher [mailto:matthias8...@gmx.at] *Gesendet:* Donnerstag, 21. Mai 2015 13:27 *An:* fop-users@xmlgraphics.apache.org *Betreff:* Re: Question about Font selection Hi Markus, I'm not sure if this can be done with the fop config file. For fallbacks to other fonts inside SVGs, I normally add a second font to the SVG text element directly. So instead of just having font-family:'Lucida sans unicode'; I automatically add another font: font-family:'Lucida sans unicode','Arial Unicode MS'. HTH, Matthias On 19.05.2015 06:58, markus.sticker.e...@zf.com mailto:markus.sticker.e...@zf.com wrote: Hi, my major issue is about math symbols and symbols in general. Just I had an issue about the symbol font on windows, now I use the GNU FreeFonts instead of the windows fonts, because they delivered the wrong character presentation. Now I want to set the fallback to the ArialUnicode. You can see I set the Arial to “any”. In my SVG I use the Glyph “bracerightvertical”, one time as “lucida sans unicode” (this does the thrid party math exporter) and one time I use “Arial” If Arial is set as font-family the glyph is drawn. The log mentioned that lucida is replaced by any. Any is configured to Arial Unicode. But FOP is look on Helvetica for the vertical braces. So my question is how to configure the fop right that the major fallback will map to this Arial Unicode? (so that also other fonts, I don’t know today, will have a lookup on the Arial Unicode) Attached you will find my current configuration, fo File, pdf and the SVG. Thanks for your help. Best Regards Markus - To unsubscribe, e-mail:fop-users-unsubscr...@xmlgraphics.apache.org mailto:fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail:fop-users-h...@xmlgraphics.apache.org mailto:fop-users-h...@xmlgraphics.apache.org xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xmlns:svg=http://www.w3.org/2000/svg; xmlns:i=http://ns.adobe.com/AdobeIllustrator/10.0/; xmlns:xlink=http://www.w3.org/1999/xlink; xsl:strip-space elements=*/ xsl:template match=i:pgf/ xsl:template match=* xsl:copy xsl:apply-templates select=@* | node()/ /xsl:copy /xsl:template xsl:template match=@* xsl:copy-of select=current()/ /xsl:template xsl:template match=@font-family priority=1 xsl:attribute name=font-family xsl:value-of select=./ xsl:if test=not(contains(., 'Arial Unicode MS')) xsl:text,Arial Unicode MS/xsl:text /xsl:if /xsl:attribute /xsl:template xsl:template match=@style priority=1 xsl:attribute name=style xsl:choose xsl:when test=contains(., 'font-family:') and not(contains(., 'Arial Unicode MS')) xsl:value-of select=substring-before(., 'font-family:')/ xsl:textfont-family:/xsl:text xsl:variable name=rest select=substring-after(., 'font-family:')/ xsl:choose xsl:when test=contains($rest, ';') xsl:value-of select=substring-before($rest, ';')/ xsl:text,Arial Unicode MS;/xsl:text xsl:value-of select=substring-after($rest, ';')/ /xsl:when xsl:otherwise xsl:text,Arial Unicode MS;/xsl:text /xsl:otherwise /xsl:choose /xsl:when xsl:otherwise xsl:value-of select=./ /xsl:otherwise /xsl:choose /xsl:attribute /xsl:template /xsl:stylesheet - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Question about Font selection
Hi Markus, I'm not sure if this can be done with the fop config file. For fallbacks to other fonts inside SVGs, I normally add a second font to the SVG text element directly. So instead of just having font-family:'Lucida sans unicode'; I automatically add another font: font-family:'Lucida sans unicode','Arial Unicode MS'. HTH, Matthias On 19.05.2015 06:58, markus.sticker.e...@zf.com wrote: Hi, my major issue is about math symbols and symbols in general. Just I had an issue about the symbol font on windows, now I use the GNU FreeFonts instead of the windows fonts, because they delivered the wrong character presentation. Now I want to set the fallback to the ArialUnicode. You can see I set the Arial to “any”. In my SVG I use the Glyph “bracerightvertical”, one time as “lucida sans unicode” (this does the thrid party math exporter) and one time I use “Arial” If Arial is set as font-family the glyph is drawn. The log mentioned that lucida is replaced by any. Any is configured to Arial Unicode. But FOP is look on Helvetica for the vertical braces. So my question is how to configure the fop right that the major fallback will map to this Arial Unicode? (so that also other fonts, I don’t know today, will have a lookup on the Arial Unicode) Attached you will find my current configuration, fo File, pdf and the SVG. Thanks for your help. Best Regards Markus - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: part of an SVG image as link
Hi, as far as I know, this currently isn't possible. But there is a Patch for it, see: https://issues.apache.org/jira/browse/FOP-1572 Best regards, Matthias On 11.08.2015 04:22, Olof wrote: Hi I would like to create an internal link in the pdf document from a part of an image. The image format is an SVG image. Can this be accomplished in some way? Modifying the SVG isn't ruled out if that's needed to solve it. I've seen it done with pdf:s created from Latex but not pdf:s created from fop. Kind Regards, Olof Wolgast - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: FOP2.0 taking more time format complex script documents
Hi,
thanks for your analysis. I've committed a fix as part of
https://issues.apache.org/jira/browse/FOP-2530
Best regards,
Matthias
On 11.08.2015 11:36, dvineshku...@gmail.com wrote:
> Hi,
>
> After analysis, found a bug in MultiByteFont::findGlyphIndex() method.
> In FOP2.0, MultiByteFont::findGlyphIndex() method, for loop is continous
> even after a glyph character is found. Updated the findGlyphIndex() method
> to terminate the loop once the glyph character is found and performance got
> improved much. Refer below existing and updated method.
>
> Existing:
>
> public int findGlyphIndex(int c) {
> int idx = c;
> int retIdx = SingleByteEncoding.NOT_FOUND_CODE_POINT;
>
> // for most users the most likely glyphs are in the first cmap
> segments (meaning the one with
> // the lowest unicode start values)
> if (idx < NUM_MOST_LIKELY_GLYPHS && mostLikelyGlyphs[idx] != 0) {
> return mostLikelyGlyphs[idx];
> }
> for (CMapSegment i : cmap) {
> if (retIdx == 0
> && i.getUnicodeStart() <= idx
> && i.getUnicodeEnd() >= idx) {
> retIdx = i.getGlyphStartIndex()
> + idx
> - i.getUnicodeStart();
> if (idx < NUM_MOST_LIKELY_GLYPHS) {
> mostLikelyGlyphs[idx] = retIdx;
> }
> }
> }
> return retIdx;
> }
>
> Updated:
>
> public int findGlyphIndex(int c) {
> int idx = c;
> int retIdx = SingleByteEncoding.NOT_FOUND_CODE_POINT;
>
> // for most users the most likely glyphs are in the first cmap segments
> (meaning the one with
> // the lowest unicode start values)
> if (idx < NUM_MOST_LIKELY_GLYPHS && mostLikelyGlyphs[idx] != 0) {
> return mostLikelyGlyphs[idx];
> }
>
> for (int i = 0; (i < cmap.size()) && retIdx == 0; i++) {
> if (cmap.get(i).getUnicodeStart() <= idx
> && cmap.get(i).getUnicodeEnd() >= idx) {
>
> retIdx = cmap.get(i).getGlyphStartIndex()
> + idx
> - cmap.get(i).getUnicodeStart();
> if (idx < NUM_MOST_LIKELY_GLYPHS) {
> mostLikelyGlyphs[idx] = retIdx;
>
> }
> }
> }
> return retIdx;
> }
>
> Regards,
> Vinesh Kumar. D
>
>
>
>
> --
> View this message in context:
> http://apache-fop.1065347.n5.nabble.com/FOP2-0-taking-more-time-to-format-complex-script-documents-tp42461p42749.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Linking SVG-test to Nameddest in PDF
Hi, as far as I know, this is currently not possible, but you could try the following patch: https://issues.apache.org/jira/browse/FOP-1648 BR, Matthias On 09.06.2016 07:09, markus.sticker.e...@zf.com wrote: > > Hi, > > > > I just trying to link form an embedded svg to the title of the next > chapter within the same pdf. > > Is that possible with FOP and batik? > > > > This is what I tried these days: > > > > > xlink:title="Verweis zu einer SVG-Grafik"> > > > style="fill:mintcream; stroke:black;" /> > > > > > > > xlink:title="Verweis zu www.w3.org"> > > > style="fill:chartreuse; stroke:black;" /> > > > > > > Without success. > > Kind regards > > Markus > > >
Re: Misplaced table border using rl-tb writing mode
Hi, you might try this patch: https://issues.apache.org/jira/browse/FOP-2570 BR, Matthias On 08.06.2016 09:33, Maxime Bégnis wrote: > I came up with this strange behavior using using rl-tb writing mode in > a PDF output: > > in case of an horizontal merged cell in a table, the table border for > that cell is placed in the middle of the cell. > > Attached is an FO file that reproduces the issue. > > I'm using FOP 2.1 (from > https://xmlgraphics.apache.org/fop/download.html) under Ubuntu 14.04 > LTS Linux. > > I don't know if I'm doing something wrong, if there is a way around it > or if this is a bug. > > -- > -- > *NeoDoc* > *Maxime Bégnis* > max...@neodoc.fr > Tél: +33 (0)4.42.52.24.20 > 789 Rue de La Gare > 13770 Venelles > France > http://www.neodoc.fr/ > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Another SVG does not render with Batik
Hi, yes, please create a JIRA bug report with a sample SVG/FO file. Thanks, Matthias On 03.02.2016 07:50, Thomas Radtke wrote: > Hi all, > > several weeks ago I reported an SVG that does render in FOP 1.0, but > doesn't in FOP 2.0. I managed to identify a clipping being the reason. > > Again, I have a graphic that refuses to be rendered in Batik, this > time it *might be* shading. The error message: > > SEVERE: SVG graphic could not be built. Reason: > org.apache.batik.bridge.BridgeException: lfhy/lfhy/aufhaengung-1.svg > (No such file or directory) > > The path is wrong. Like last time, there is no lfhy/lfhy. > > Please help. I can impossibly go through hundreds of SVGs and find > workarounds. May I send the image? > > Thanks, > > Thomas > > -- > > > i.A. Dr. Thomas Radtke > Technische Redaktion / Technical Writer > Tel. +49 4498 89-64 > > HANSA Ventilatoren- und Maschinenbau Neumann GmbH Stockweg 19 26683 > Saterland (Germany) Phone +49 4498 890 Fax +49 4498 687 Internet: > www.hansa-klima.de E-Mail: i...@hansa-klima.de Registergericht > Oldenburg, HRB 151863 Geschäftsführer: Rolf Neumann, Jan Neumann, > Carsten Fenne >
Re: Embed 3D pdf
Hi, I think you need to use the newest, still unreleased version of the FOP pdf image plugin in order to make this work. Do SVN Checkout of https://svn.apache.org/repos/asf/xmlgraphics/fop-pdf-images/trunk and make ant build. Don't forget to include the updated pdfbox/fontbox/jempbox libs contained in the lib sub directory in your class path. HTH, Matthias On 22.03.2016 11:32, PPHSKA wrote: > Hello, > > Beginner here. I tried to embed a simple 3D PDF using > > The output PDF does contain two buttons I inserted and I got no error > messages. However the .u3d model that was included in the 3D PDF is missing > in the output PDF. Are 3D PDF not supported or do I need additional > Plug-Ins? Any help is highly appreciated! > > Cheers > > > > -- > View this message in context: > http://apache-fop.1065347.n5.nabble.com/Embed-3D-pdf-tp43738.html > Sent from the FOP - Users mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Dynamically insert SVG graphics in the XML passed to FOP
Hi,
you should try to write out the SVG Elements with the following method
(instead of using a string):
handler.startElement(String namespaceURI, String localName,
String qName, Attributes atts)
handler.endElement(String namespaceURI, String localName,
String qName)
e.g.
handler.startElement("http://www.w3.org/2000/svg;, "svg", "svg:svg", atts)
handler.startElement("http://www.w3.org/2000/svg;, "svg", "svg:g", atts)
handler.endElement("http://www.w3.org/2000/svg;, "svg", "svg:svg")
handler.endElement("http://www.w3.org/2000/svg;, "svg", "svg:g")
etc.
Best regards,
Matthias
On 21.06.2017 13:53, Pierre Caron wrote:
> Hello,
>
> I have a rather trivial problem that I haven't found a solution yet.
>
> I want to insert dynamically generated SVG code Inside the XML data
> which is supplied to FOP.
>
> To make things simpler, suppose you start from the ExampleObj2PDF
> found in FOP Embedding page
> (https://xmlgraphics.apache.org/fop/2.2/embedding.html#ExampleObj2PDF)
> and that you add a method in the ProjectTeam entity that generates a
> SVG String :
>
>
> public String getDynamicSVG() {
> return " \n" + ... +
> "";
> }
>
> (http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/model/ProjectTeam.java?view=markup)
>
>
> And that this method would be called by the following line inside
> ProjectTeamXMLReader class
>
> handler.element("SVGdynamique",projectMember.getDynamicSVG());
> (http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/examples/embedding/java/embedding/model/ProjectTeamXMLReader.java?view=markup)
>
> The question is : how to prevent the SVG tags from being escaped into
> and ? Below is the XML code I'm getting :
>
> ...
> svg:svg width="20" height="20"
> svg:g style="fill:red; stroke:#00"
> svg:rect x="0" y="0" width="15" height="15"/
> svg:rect x="5" y="5" width="15" height="15"/
> /svg:g
> /svg:svg
> ...
>
> In the final step, the SVG string would be merged by the
> projectteam2fo.xsl like this :
>
>
>
> http://www.w3.org/2000/svg;
> width="20" height="20">
>
>
> ]
>
>
> Is there a way to prevent the escaping?
>
> Note that the SVG tags get escaped during the XML processing by SAX
> not during the insertion into the xsl file.
>
> Any help would be greatly appreciated!
>
> Pierre Caron
>
Re: Dynamically insert SVG graphics in the XML passed to FOP
Hi,
On 24.06.2017 00:50, Pierre Caron wrote:
> Thank you Matthias. I was able to generate valid SVG code with this :
>
> handler.startElement("svgDynamique");
> handler.startElement("http://www.w3.org/2000/svg;, "svg", "svg
> width=\"20\" height=\"20\"", EMPTY_ATTS);
> handler.startElement("g style=\"fill:red; stroke:#00\"");
Don't use handler.startElement witout specifying a namespace and the
attributes (such as "style") should be specified as last parameter of
the startElement method call.
> handler.element("rect x=\"0\" y=\"0\" width=\"15\"
> height=\"15\"", "");
> handler.element("rect x=\"5\" y=\"5\" width=\"15\"
> height=\"15\"", "");
Same here. Use startElement with namespace and fix attribute.
> handler.endElement("g");
> handler.endElement("http://www.w3.org/2000/svg;, "svg", "svg");
> handler.endElement("svgDynamique");
>
> which yielded :
>
>
>xmlns="http://www.w3.org/2000/svg;>
>
>height="15"/>
>height="15"/>
>
>
>
>
> Now, the problem is inserting this code in the fo template. I have tried
> the following :
>
>
>
>
> disable-output-escaping="yes" />
> ]
>
>
>
> but I get the following message which suggest that the SVG code isn't
> present :
>
> org.apache.fop.fo.ValidationException: "fo:instream-foreign-object" is
> missing child elements. Required content model: one (1) non-XSL namespace
> child (No context info available)
>
> I have also tried without success either :
>
>
should work.
> My second question is : if the SVG is generated through Batik, how do you
> embed it in the fo file?
You will need to parse the SVG file and insert it into the FO file via
DOM operations or you use the fo:external-graphic element and specify as
source the SVG file.
Best regards,
Matthias
> Again, thank you very much!
>
>
>
> --
> View this message in context:
> http://apache-fop.1065347.n5.nabble.com/Dynamically-insert-SVG-graphics-in-the-XML-passed-to-FOP-tp45237p45239.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange error with the first word in figure and table titles
Hi Bernhard, you'll have to provide a XSL-FO fragment, so that we can help you. Probably you'll see what the problem is, as soon as you examine it yourself. Unfortunately I don't know, how the XSL-FO fragment can be dumped with Oxygen before it is converted to PDF. Best regards, Matthias On 21.11.2018 05:07, Bernhard Kleine wrote: > > Hi, (my first contribution) > > using docbook 5.1 with oxygen 20.1 for a book I happened to meet a > strange error. The font for the entire work is Alagreya, however, the > first word of figure and table captions are in Times Roman. As Bob > Stayton confirmed, there is not any mentioning of Times Roman in the > xml I wrote, nor in the customization I adapted. It is only this first > word. Bob thinks this is an error with FOP. Where do I report such errors? > > Thanks for reading. > > Greetings from the Black Forest > > Bernhard > > -- > spitzhalde9 > D-79853 lenzkirch > bernhard.kle...@gmx.net > www.b-kleine.com, www.urseetal.net > - > thunderbird mit enigmail > GPG schlüssel: D5257409 > fingerprint: > 08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09
Re: White space in FO causes PDF TOC problem
Hi, yes, this is an unresolved FOP bug, see also: https://issues.apache.org/jira/browse/FOP-1952 https://issues.apache.org/jira/browse/FOP-1839 Best regards, Matthias On 26.11.2018 01:21, Mark Giffin wrote: > I'm using FOP 2.3 with the DITA Open Toolkit. The tags in DITA > topics are used in the table of contents in a PDF. Each table of > contents line is justified like this in the PDF: > > (left margin)Intro to > XYZ14(right > margin) > (left margin)Setting Up > XYZ...18(right margin) > > Most lines line up neatly on the right margin, but a few do not go to > the margin. The cause of a line that does not go all the way to the > right margin is a tag with white space in it like this: > > > Do This First > > > This white space gets copied over to the XSL-FO produced by the DITA OT: > > height="150%"> > Do This First > keep-together.within-line="always" start-indent="-14pt"> color="black" leader-pattern="dots"/> > And FOP renders this in the PDF like this, where the line does not go > all the way to the right margin: > > (left margin)Do This > First10 (right > margin) > (left margin)Intro to > XYZ14(right > margin) > (left margin)Setting Up > XYZ...18(right margin) > > When I remove the whitespace in the XSL-FO, the line renders > correctly, all the way to the right margin. Both Antenna House and XEP > render the line correctly, ignoring the extraneous whitespace. This > seems like a FOP bug, is there a fix for this? Other than removing the > whitespace? > > Thanks, > Mark > > > - > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Set Adobe Acrobat Language
Hi, try to set the language attribute in the fo:root element, e.g.: BR, Matthias On 07.06.2019 17:29, Stefan Kleinbaum wrote: > Dear FOP developers, > > how can I set the document language property in adobe acrobat reader? > (Open a document > right click on "document properties" > advanced > > language) > > language.png > > What is the correct metadata property for that? > > Many thanks in advance > Stefan
Re: fop-users Digest 10 Jun 2019 03:00:01 -0000 Issue 3290
Hi, works for me... see attachments. Matthias On 14.06.2019 17:42, Stefan Kleinbaum wrote: > Hi, > > I tried it out but unfortunately it is not working. The language field > is empty like before. > > Best > > > > -- Forwarded message -- > From: Matthias Reischenbacher <mailto:matthias8...@gmx.at>> > To: fop-users@xmlgraphics.apache.org > <mailto:fop-users@xmlgraphics.apache.org> > Cc: > Bcc: > Date: Fri, 7 Jun 2019 18:40:00 -0300 > Subject: Re: Set Adobe Acrobat Language > > Hi, > > try to set the language attribute in the fo:root element, e.g.: > > > > BR, > Matthias > > On 07.06.2019 17:29, Stefan Kleinbaum wrote: >> Dear FOP developers, >> >> how can I set the document language property in adobe acrobat >> reader? (Open a document > right click on "document properties" > >> advanced > language) >> >> language.png >> >> What is the correct metadata property for that? >> >> Many thanks in advance >> Stefan > language_de.xml.pdf Description: Adobe PDF document http://www.w3.org/1999/XSL/Format; language="en"> test language_en.xml.pdf Description: Adobe PDF document http://www.w3.org/1999/XSL/Format; language="de"> test - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
