fop.jar's MANIFEST.MF
Hi all, Does anyone know the why the Build-Id property of the MANIFEST.MF file should include the ant property 'java.runtime.version', yet not the 'javac.target' property used by the javac task in the compile target? I appreciate that the version of the JVM running ant may perhaps affect the build process, but is it not more useful to have info on the JVM that the fop.jar is compiled for? Thanks for any comments in advance, Peter
Re: trying to debug using eclipse
Hi Martin, Martin Edge wrote: Within eclipse it says it's within the 'build path' or do you mean within Java's class path? You need to refresh the directory for Eclipse to take into account new files created by the build process. Select the project in the Package Explorer view and press ‘F5’, or right-click and select ‘Refresh’. HTH, Vincent From: Peter Hancock Sent: Sunday, 7 February 2010 7:08 PM To: fop-dev@xmlgraphics.apache.org; martin.e...@intellimail.com.au Subject: Re: trying to debug using eclipse Hi Martin Is build/gensrc on your classpath? This gets generated during the default ant task. Pete On Sat, Feb 6, 2010 at 3:28 AM, martin.e...@asmorphic.net.au wrote: Hi Guys, Wondering if there are any tips of what i'm doing wrong - have built the application using ant, and it says it was built successfully. Can see the event-models.xml in the accessibility section, however, when running the application from eclipse, I get: NFO: Default page-width set to: 210mm Exception in thread main java.lang.ExceptionInInitializerError at org.apache.fop.apps.FOUserAgent.init(FOUserAgent.java:102) at org.apache.fop.apps.FopFactory.newFOUserAgent(FopFactory.java:188) at org.apache.fop.cli.CommandLineOptions.parse(CommandLineOptions.java:171) at org.apache.fop.cli.Main.startFOP(Main.java:158) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.util.MissingResourceException: File event-model.xml not found at org.apache.fop.events.model.AbstractEventModelFactory.loadModel(AbstractEven tModelFactory.java:46) at org.apache.fop.accessibility.AccessibilityEventProducer$EventModelFactory.cr eateEventModel(AccessibilityEventProducer.java:54) at org.apache.fop.events.DefaultEventBroadcaster.clinit(DefaultEventBroadcast er.java:73) ... 5 more Any suggestions on where I should start looking? THanks Martin
DO NOT REPLY [Bug 48696] New: AFP rendering of bitmap images broke between revs 829021 and 829061
https://issues.apache.org/bugzilla/show_bug.cgi?id=48696 Summary: AFP rendering of bitmap images broke between revs 829021 and 829061 Product: Fop Version: 1.0dev Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: peter.hanc...@gmail.com This bug manifests when printing. Attached are afps generated at rev 829021 (ok) and rev 829061 (broken). The jpgs show scans of the printed output and an error message printed for rev 829061. The resources used to generate the documents are also attached. Note that changes were made to the Xml Graphics Commons library at the same time. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48696] AFP rendering of bitmap images broke between revs 829021 and 829061
https://issues.apache.org/bugzilla/show_bug.cgi?id=48696 --- Comment #1 from Peter Hancock peter.hanc...@gmail.com 2010-02-08 04:11:35 UTC --- Created an attachment (id=24938) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24938) example of bug -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 Vincent Hennebert vhenneb...@gmail.com changed: What|Removed |Added Component|pdf |page-master/layout Platform|PC |All Version|0.20.5 |all Summary|Arabic words are broken for |[PATCH] Arabic Shaping not |rendering PDF from FOP |Supported by FOP OS/Version|Windows 2000|All Severity|critical|normal --- Comment #7 from Vincent Hennebert vhenneb...@gmail.com 2010-02-08 04:13:10 UTC --- Hi, Thanks for your patch. Do you have an example FO file that could be used for testing purpose (even better, with an English translation)? IIUC, Arabic shaping is about replacing glyphs for standalone letters with suitable ligature glyphs for building words. Surely that affects character widths, so line breaking decisions? In the patch, shaping is performed at the rendering stage, so isn't there a danger of getting inconsistent results? Also, IIC Arabic shaping affects glyphs selection. How do you make sure that the right glyphs are being embedded in the PDF file? The same piece of code is duplicated in the PCL and PDF painters. The same would probably also need to be done for other painters. This is not desirable. Finally, what is the impact on performance? It looks like shaping will be applied to just any text, even non-arabic one. Thanks, Vincent (In reply to comment #3) Created an attachment (id=24934) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24934) [details] Support for Arabic PDF rendering using ICU4J This patch uses ICU4J to do form-shaping and BIDI transformation of rendered text. It is a patch for the FOP trunk. It does not change the layout manager or the area tree handler or allow a writing-mode other than “lr-tb”. For this patch to be integrated with FOP, FOP would need to distribute the ICU4J library - icu4j-4_2_1.jar. It affects both PDF and PCL rendering but has only been tested with PDF rendering. So far results of testing with PDF rendering have been positive. The PCL aspect of the patch looks correct given that the PDF aspect works. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48697] New: Span problem with tables spanning pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=48697 Summary: Span problem with tables spanning pages Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: blocker Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: phewl...@oats.co.uk Created an attachment (id=24940) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24940) FOP Output The document body has three columns fo:region-body column-count=3, and each of the tables are contained within fo:block span=all. When a table spans onto the next page, the starting point for the next block is set to the next column. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48697] Span problem with tables spanning pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=48697 --- Comment #1 from phewl...@oats.co.uk 2010-02-08 04:25:13 UTC --- Created an attachment (id=24942) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24942) FO -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46778] image not found
https://issues.apache.org/bugzilla/show_bug.cgi?id=46778 Dominik Stadler dominik.stad...@gmx.at changed: What|Removed |Added CC||dominik.stad...@gmx.at --- Comment #2 from Dominik Stadler dominik.stad...@gmx.at 2010-02-08 04:56:40 UTC --- I saw a similar issue with 0.95, I could not get FOP to find the images when I used relative pathes and the baseDir. Prepending file:/// in the baseDir also did not have any effect. In the end I prepended the full path in the XSL-FO file to load the images correctly. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48696] AFP rendering of bitmap images broke between revs 829021 and 829061
https://issues.apache.org/bugzilla/show_bug.cgi?id=48696
--- Comment #2 from Harald G. Henne afput...@web.de 2010-02-08 06:04:25 UTC
---
Hi,
there is only a small diff between 829021 and 829061
and the resuling print out depends on some printer characteristic.
|829021 |829061
---+-+---+
IBM Infoprint IP70 | OK | 0420-486 either not valid or not supported|
OCE printer| OK | OK|
| | |
IBM workbench | OK | OK| ver
2.05.04.01
BTB Afp Browser| no image| OK| ver
1.30
ISIS plugin| no image| no image | ISIS
Papyrus AFP Viewer V.7.01/w3
Both writes out a IOCA function set 11 image and 829061 write out an
additional 0x9B IDE Structure parameter.
0x9B: IDE Structure parameter [6]
Flags:0x00 (- Additive)
(- Gray Coding: off)
Format: 0x01 (RGB)
Reserved: 00 00 00
Size1:0x08 (8)
Accouding to ioca_S550-1142-00.pdf the only valid format bytes for
IDESZ=8 is
X'02' YCrCb (see Note 2)
X'12' YCbCr (see Note 2)
Note 2:
Notes on parameters used when IDESZ=4 or IDESZ=8:
Grayscale images only. Grayscale IDEs are composed of the Y component only
of the YCrCb or YCbCr color model.
--
dump of revison 829061:
0xD3A8CE: BR Begin Resource [20] (Offset ???)
RES2
Reserved: 00 00
T21: Resource Object Type (R) [8]
ObjType:0x06 (Image (IOCA) object (retired))
ConData:00 00 00 00 00 00 00
{
0xD3A8FB: BIM Begin Image Object [8] (Offset ???)
IMG2
{
0xD3A8C7: BOG Begin Object Environment Group [8] (Offset ???)
OEG2
{
0xD3A66B: OBD Object Area Descriptor [20] (Offset ???)
T43: Descriptor Position [1]
DesPosID: 0x01 (1)
T4B: Object Area Measurement Units [6]
XoaBase:0x00 (10 inches)
YoaBase:0x00 (10 inches)
XoaUnits: 0x0960 (2400)
YoaUnits: 0x0960 (2400)
T4C: Object Area Size [7]
SizeType: 0x02 (2)
XoaSize:0x0001E0 (480)
YoaSize:0x0001E0 (480)
0xD3AC6B: OBP Object Area Position [24] (Offset ???)
OAPosID:0x01 (1)
RGLength: 0x17 (23)
XoaOSet:0x00 (0)
YoaOSet:0x00 (0)
XoaOrent: 0x (0 degree)
YoaOrent: 0x2D00 (90 degree)
Reserved: 00
XocaOSet: 0x00 (0)
YocaOSet: 0x00 (0)
XocaOrent: 0x (0 degree)
YocaOrent: 0x2D00 (90 degree)
RefCSys:0x00 (origin defined by IPS)
0xD3ABFB: MIO Map IO Image Object [5] (Offset ???)
000 RGLength: 0x0005 (5)
T04: Mapping Option [1]
MapValue: 0x60 (Scale to Fill)
0xD3A6FB: IDD Image Data Descriptor IO [13] (Offset ???)
UnitBase: 0x00 (10 inches)
XResol: 0x02D0 (720)
YResol: 0x02D0 (720)
XSize: 0x0258 (600)
YSize: 0x0258 (600)
0xF7: IOCA Function Set Identification [2]
Category: 0x01 (Function Set identifier)
FcnSet: 0x0B (11)
}
0xD3A9C7: EOG End Object Environment Group [8] (Offset ???)
OEG2
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
0xD3EEFB: IPD Image Picture Data IO [8192] (Offset ???)
DO NOT REPLY [Bug 48696] AFP rendering of bitmap images broke between revs 829021 and 829061
https://issues.apache.org/bugzilla/show_bug.cgi?id=48696 --- Comment #3 from Harald G. Henne afput...@web.de 2010-02-08 06:07:07 UTC --- sorry the table was messed up: printer and viewer test |829021 |829061 ---+-+---+ IBM Infoprint IP70 | OK | 0420-486 either not valid or not supported| OCE printer| OK | OK| | | | IBM workbench | OK | OK| BTB Afp Browser| no image| OK| ISIS plugin| no image| no image | IBM workbench ver 2.05.04.01 BTB Afp Browser v 1.30 ISIS Papyrus AFP Viewer V.7.01/w3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #8 from Jonathan Levinson levin...@intersystems.com 2010-02-08 06:58:15 UTC --- Hi Vincent, I will attach the .fo file I've been using for testing. I will also attach the generated pdf. This is from an example our Dubai team gave me for my own testing as I developed the code. Our Dubai team has been testing with a large variety of Arabic script - but they are using a report creation tool that invokes fop.bat with xsl input so the .fo file isn't part of their output. I could give them instructions for creating .fo files. We have found in testing that what is most important is the BIDI algorithm is applied so that text (including embedded numerals) is in the right order and that form shaping is correct. You need to know the Arabic alphabet and its rules to assess the output of testing. We have a team that knows Arabic to do our testing. They eyeball the reports to make sure they are in proper Arabic with text and sub-text in the right order. Embedded numerals can be in a different order - left-to-right rather than right-to-left. It isn't clear to me how this process can be automated. You are right that widths change and this could change line breaking decisions. Do you know where in the FOP pipeline before we reach the rendering pipeline the Arabic shaping could go so as to be able to affect width selection? I believe that what ensures the right glyphs are embedded in the PDF file is the nature of the ICU4J algorithm which transforms the UNICODE representation of the string. The output for our Dubai team is PDFs with embedded fonts and these are working so ICU4J must have solved the problem in some way, and I believe the way they solve it is by using different UNICODE codes. I don't have performance numbers to give you yet. If ICU4J was clever about the way they wrote their transform algorithm it should not be much of a performance impact since they only need to transform text in the Arabic UNICODE code range and testing whether text is in this range should be quick. Thanks, Jonathan (In reply to comment #7) Hi, Thanks for your patch. Do you have an example FO file that could be used for testing purpose (even better, with an English translation)? IIUC, Arabic shaping is about replacing glyphs for standalone letters with suitable ligature glyphs for building words. Surely that affects character widths, so line breaking decisions? In the patch, shaping is performed at the rendering stage, so isn't there a danger of getting inconsistent results? Also, IIC Arabic shaping affects glyphs selection. How do you make sure that the right glyphs are being embedded in the PDF file? The same piece of code is duplicated in the PCL and PDF painters. The same would probably also need to be done for other painters. This is not desirable. Finally, what is the impact on performance? It looks like shaping will be applied to just any text, even non-arabic one. Thanks, Vincent (In reply to comment #3) Created an attachment (id=24934) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24934) [details] [details] Support for Arabic PDF rendering using ICU4J This patch uses ICU4J to do form-shaping and BIDI transformation of rendered text. It is a patch for the FOP trunk. It does not change the layout manager or the area tree handler or allow a writing-mode other than “lr-tb”. For this patch to be integrated with FOP, FOP would need to distribute the ICU4J library - icu4j-4_2_1.jar. It affects both PDF and PCL rendering but has only been tested with PDF rendering. So far results of testing with PDF rendering have been positive. The PCL aspect of the patch looks correct given that the PDF aspect works. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #9 from Jonathan Levinson levin...@intersystems.com 2010-02-08 07:00:33 UTC --- Created an attachment (id=24947) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24947) Example fo - one of many used in testing Arabic patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #10 from Jonathan Levinson levin...@intersystems.com 2010-02-08 07:01:31 UTC --- Created an attachment (id=24948) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24948) generated PDF from sample .fo -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48696] AFP rendering of bitmap images broke between revs 829021 and 829061
https://issues.apache.org/bugzilla/show_bug.cgi?id=48696 --- Comment #5 from Peter Hancock peter.hanc...@gmail.com 2010-02-08 08:34:50 UTC --- Thanks for your input, Harald. Chaging the Format field of the IDE Structure parameter to YCrCb, produced a desirable printed output. The IDEStructureParameter class defaults this property to RGB, and it is not set by the process for b+w color images. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Font Loading via IF Rendering.
Hey Guys, Trying to get to the bottom of my inability to generate a PostScript file from Intermediate File. Don't know much about the structure of the code, so I thought I'd comment on what I've seen and see if there is any suggestion on where to look. When converting from IF - PS (and the original IF was generated with a application/postscript MIME tag), In PSPainter.java - In function drawText function: fontKey = getFontInfo().getInternalFontKey(triplet); Returns a null for my given font, even though the font was _not_ complained about when I loaded I did notice when reviewing the 'triplets' collection that for all entries in there, there was a substantial amount of null entries (like the loading of some fonts failed?) What populates the triplets collection? Thanks Martin.
RE: Font Loading via IF Rendering.
Hi Guys,
Also noticed, when Im performing the IF - PS Conversion...
The method which I'm guessing is to setup fonts doesn't seem to be called
anywhere?
public static void setupFonts(IFDocumentHandler documentHandler, FontInfo
fontInfo)
throws FOPException {
This is in IFUtil.java.
So I am unsure where the font collection is actually being setup (if it is
at all) and if it is not, well I'm guessing this is the source of my
problem.
Thanks
Martin
-Original Message-
From: Martin Edge [mailto:martin.e...@intellimail.com.au]
Sent: Tuesday, 9 February 2010 9:46 AM
To: 'fop-dev@xmlgraphics.apache.org'
Subject: Font Loading via IF Rendering.
Hey Guys,
Trying to get to the bottom of my inability to generate a PostScript file
from Intermediate File.
Don't know much about the structure of the code, so I thought I'd comment on
what I've seen and see if there is any suggestion on where to look.
When converting from IF - PS (and the original IF was generated with a
application/postscript MIME tag),
In PSPainter.java - In function drawText function:
fontKey = getFontInfo().getInternalFontKey(triplet);
Returns a null for my given font, even though the font was _not_ complained
about when I loaded
I did notice when reviewing the 'triplets' collection that for all entries
in there, there was a substantial amount of null entries (like the loading
of some fonts failed?)
What populates the triplets collection?
Thanks
Martin.
RE: Font Loading via IF Rendering.
Hey Guys,
From what I can ascertain, when converting from IF - PS, the Intermediate
classes don't load the installed fonts, nor the configured fonts.
AbstractBinaryWritingIFDocumentHandler.java
Method: public void setDefaultFontInfo(FontInfo fontInfo) {
Currently has:
FontManager fontManager =
getUserAgent().getFactory().getFontManager();
FontCollection[] fontCollections = new FontCollection[] {
new
Base14FontCollection(fontManager.isBase14KerningEnabled())
};
Which when you get to the point of getInternalFontKey and look at the
triplets object, it seems to only contain the Base14 Fonts. What I found out
though, is if I put the following:
FontManager fontManager =
getUserAgent().getFactory().getFontManager();
Graphics2D graphics2D =
Java2DFontMetrics.createFontMetricsGraphics2D();
FontCollection[] fontCollections = new FontCollection[] {
new
Base14FontCollection(fontManager.isBase14KerningEnabled()),
new InstalledFontCollection(graphics2D)
};
Where I have reused the same method of retrieving the 2D fonts, and install
my special font, suddenly it can find the font in the triplets collection
and moves forward to render. It doesn't seem to render the font correctly,
but the point in this test was to show that the existing font configuration
in this scenario is not being loaded.
What do you think?
Martin
-Original Message-
From: Martin Edge [mailto:martin.e...@intellimail.com.au]
Sent: Tuesday, 9 February 2010 10:40 AM
To: 'fop-dev@xmlgraphics.apache.org'
Subject: RE: Font Loading via IF Rendering.
Hi Guys,
Also noticed, when Im performing the IF - PS Conversion...
The method which I'm guessing is to setup fonts doesn't seem to be called
anywhere?
public static void setupFonts(IFDocumentHandler documentHandler, FontInfo
fontInfo)
throws FOPException {
This is in IFUtil.java.
So I am unsure where the font collection is actually being setup (if it is
at all) and if it is not, well I'm guessing this is the source of my
problem.
Thanks
Martin
-Original Message-
From: Martin Edge [mailto:martin.e...@intellimail.com.au]
Sent: Tuesday, 9 February 2010 9:46 AM
To: 'fop-dev@xmlgraphics.apache.org'
Subject: Font Loading via IF Rendering.
Hey Guys,
Trying to get to the bottom of my inability to generate a PostScript file
from Intermediate File.
Don't know much about the structure of the code, so I thought I'd comment on
what I've seen and see if there is any suggestion on where to look.
When converting from IF - PS (and the original IF was generated with a
application/postscript MIME tag),
In PSPainter.java - In function drawText function:
fontKey = getFontInfo().getInternalFontKey(triplet);
Returns a null for my given font, even though the font was _not_ complained
about when I loaded
I did notice when reviewing the 'triplets' collection that for all entries
in there, there was a substantial amount of null entries (like the loading
of some fonts failed?)
What populates the triplets collection?
Thanks
Martin.
