Rounding errors in AFP
Hi I'm working on a bug to get AFP to draw borders so that the horizontal and vertical lines are aligned. There are rounding errors in or.apache.fop.afp.AFPBorderPainter.java in paint(PaintingInfo paintInfo) caused by Math.round(), basically it's the age old issue of: x == y + z doesn't mean Math.round(x) = Math.round(y) + Math.round(z) (if y and z are rational) but Math.round(x) == Math.round(y+z) (if y and z are rational) We're currently using floats to represent co-ordinates, would anyone have any issues if i refactored it to use doubles? Obviously there's a memory issue here, thus my asking, but we've got integer in the Intermediate Format, the output is an integer, but we need to convert between the two. Converting an int into a float is lossy where as converting it to a double isn't, that is my reason for wanting the change. Thanks Mehdi
TrueType Font Embedding
Hi, I'm working on making TTF subset embedding configurable such that a user can opt for either full font embedding, subset embedding or just referencing, this would be extending the work Jeremias submitted. I was considering adding a parameter to the font configuration file called embedding with 3 possible values none, subset and full. This would allow the user to configure the embedding mode on a font by font basis. What do people think about this proposal? Thanks Mehdi
Re: svn commit: r1034094 - in /xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop: fonts/truetype/TTFSubSetFile.java render/ps/PSFontUtils.java
Hi Jeremias,
This code fails the build, you need to add a ; (a semi-colon) to the
last parameter in the enumerated type in
o.a.f.fonts.truetype.TTFSubSetFile. I was also curious why you made
TTFSubSetFile.GlyphHandler? Why do you make it an interface, and why
do you use an anonymous class in PSFontUtils, only to pass it back to
the same class? If there's only one implementation and if it only
contains a single method, I wouldn't have thought an interface was
necessary. TTFSubSetFile already contains various methods that perform
similar functions (i.e. take an input, convert it to the necessary
format and write to file), why couldn't this be implemented in the
handleGlyphSubset(...) method? Is there another implementation you're
making this flexible for?
Also, from a design point, why have you made each glyph a single
string? Surely if the string must finish at a glyph boundary, then we
could pack in several glyphs into the string and make it intelligent
enough not to write partial glyphs? Will this method have any
performance benefits/disadvantages? The spec says 65535 is the array
limit, will this be hit?
Thanks
Mehdi
On 11 November 2010 20:03, jerem...@apache.org wrote:
Author: jeremias
Date: Thu Nov 11 20:03:43 2010
New Revision: 1034094
URL: http://svn.apache.org/viewvc?rev=1034094view=rev
Log:
PostScript Output: Bugfix for the occasional badly rendered glyph on HP
Laserjets.
Reason: the /sfnts entry should split strings at glyph boundaries which
currently doesn't happen.
Solution: Switch to the /GlyphDirectory approach described in the section
Incremental Definition of Type 42 Fonts in the PS language reference. This
way all glyphs are separated into single strings which seems to solve the
problem. It is also much closer to the approach taken by the various
PostScript printer drivers on Windows.
Modified:
xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java
xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop/render/ps/PSFontUtils.java
Modified:
xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java?rev=1034094r1=1034093r2=1034094view=diff
==
---
xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java
(original)
+++
xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop/fonts/truetype/TTFSubSetFile.java
Thu Nov 11 20:03:43 2010
@@ -20,7 +20,6 @@
package org.apache.fop.fonts.truetype;
import java.io.IOException;
-import java.util.Iterator;
import java.util.List;
import java.util.Map;
@@ -35,6 +34,10 @@ import java.util.Map;
*/
public class TTFSubSetFile extends TTFFile {
+ private static enum OperatingMode {
+ PDF, POSTSCRIPT_GLYPH_DIRECTORY
+ }
+
private byte[] output = null;
private int realSize = 0;
private int currentPos = 0;
@@ -43,37 +46,27 @@ public class TTFSubSetFile extends TTFFi
* Offsets in name table to be filled out by table.
* The offsets are to the checkSum field
*/
- private int cvtDirOffset = 0;
- private int fpgmDirOffset = 0;
+ private MapString, Integer offsets = new java.util.HashMapString,
Integer();
private int glyfDirOffset = 0;
private int headDirOffset = 0;
- private int hheaDirOffset = 0;
private int hmtxDirOffset = 0;
private int locaDirOffset = 0;
private int maxpDirOffset = 0;
- private int prepDirOffset = 0;
private int checkSumAdjustmentOffset = 0;
private int locaOffset = 0;
- /**
- * Initalize the output array
- */
- private void init(int size) {
- output = new byte[size];
- realSize = 0;
- currentPos = 0;
-
- // createDirectory()
- }
-
- private int determineTableCount() {
+ private int determineTableCount(OperatingMode operatingMode) {
int numTables = 4; //4 req'd tables: head,hhea,hmtx,maxp
if (isCFF()) {
throw new UnsupportedOperationException(
OpenType fonts with CFF glyphs are not supported);
} else {
- numTables += 2; //1 req'd table: glyf,loca
+ if (operatingMode == OperatingMode.POSTSCRIPT_GLYPH_DIRECTORY) {
+ numTables++; //1 table: gdir
+ } else {
+ numTables += 2; //2 req'd tables: glyf,loca
+ }
if (hasCvt()) {
numTables++;
}
@@ -90,8 +83,8 @@ public class TTFSubSetFile extends TTFFi
/**
* Create the directory table
*/
- private void createDirectory() {
- int numTables =
Re: svn commit: r1034094 - in /xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop: fonts/truetype/TTFSubSetFile.java render/ps/PSFontUtils.java
I was building from the command line, using ant package and
referencing I've got the same version as you... Curious... Though I
completely agree with your comments on TTFSubSetFile, it needs a
little sprucing.
Hi Mehdi
On 12.11.2010 16:32:45 mehdi houshmand wrote:
Hi Jeremias,
This code fails the build, you need to add a ; (a semi-colon) to the
last parameter in the enumerated type in
o.a.f.fonts.truetype.TTFSubSetFile.
I don't see that. Eclipse/ECJ is happy with it and the Sun JDK 1.5.0_22
also doesn't have a problem when running the Ant build. Checking the JLS
3.0, the semicolon is optional if there's no body content after the
entries. An example from the JLS:
public class Example1 {
public enum Season { WINTER, SPRING, SUMMER, FALL }
public static void main(String[] args) {
for (Season s : Season.values()) System.out.println(s);
}
}
What environment are you working with?
I was also curious why you made
TTFSubSetFile.GlyphHandler? Why do you make it an interface, and why
do you use an anonymous class in PSFontUtils, only to pass it back to
the same class? If there's only one implementation and if it only
contains a single method, I wouldn't have thought an interface was
necessary.
It's a normal callback interface from PSFontUtils back into
TTFSubSetFile, called for each glyph when building the subset.
TTFSubSetFile already contains various methods that perform
similar functions (i.e. take an input, convert it to the necessary
format and write to file), why couldn't this be implemented in the
handleGlyphSubset(...) method?
My main problem with the way TTFSubSetFile is currently written is that
writing the records is mixed with building the table index. If that were
not so, it would have been easier to go with an approach that you would
have expected. But my approach actually has the advantage that there's
less memory build-up, since not the whole subset including glyphs has to
be buffered in memory. After all, TTF loading is known to take a LOT of
memory.
Is there another implementation you're
making this flexible for?
No. The context: my client (your employer) asked for urgent help to
resolve the problem with my first attempt at TTF subsets when printed on
HP printers. I needed a quick resolution after I found out what could be
wrong. I didn't know if I would turn out to be right until after I
committed the changes and Chris/Vincent could run tests. So I didn't
care about too much code beauty. There's actually quite a bit of
copy/paste/change in TTFSubSetFile as a result which I'm not
particularly proud of. I'm still waiting for feedback if my change
really fixed the problem although preliminary results show that the
problem is now solved. I expect that some refactoring would do
TTFSubSetFile some good.
Also, from a design point, why have you made each glyph a single
string?
That was no design decision. It's a requirement found in the PS langref
third edition, page 356, describing the contents of /GlyphDirectory.
Each glyph is looked up by its index when an array is used.
Surely if the string must finish at a glyph boundary, then we
could pack in several glyphs into the string and make it intelligent
enough not to write partial glyphs?
That would be useful if we were to keep putting the glyphs in the /sfnts
entry, but not with /GlyphDirectory.
Will this method have any performance benefits/disadvantages?
The GlyphDirectory allows to keep memory consumption down in the JavaVM.
Otherwise, I see no implications.
The spec says 65535 is the array limit, will this be hit?
I think that's unlikely. We will hardly have any font with more than
65535 glyphs and no single glyph is likely to be larger than 64KB to
describe its outline. We might still run into problems with the /sfnts
entry, though. If we can improve TTFSubSetFile it should be much easier
to stop strings at record boundaries.
snip/
Jeremias Maerki
Re: svn commit: r1034094 - in /xmlgraphics/fop/branches/Temp_TrueTypeInPostScript/src/java/org/apache/fop: fonts/truetype/TTFSubSetFile.java render/ps/PSFontUtils.java
I attempted to build the code on my home system (Windows 7, latest
java release 1.6.0_22) and I got the same thing. After some
investigation it turns our this is a known bug with maven (google
maven enum bug). It might be worth putting the semi-colon in there
to prevent anyone else facing this issue since it makes little
difference either way.
Thanks
Mehdi
On 14 November 2010 09:17, mehdi houshmand med1...@gmail.com wrote:
I was building from the command line, using ant package and
referencing I've got the same version as you... Curious... Though I
completely agree with your comments on TTFSubSetFile, it needs a
little sprucing.
Hi Mehdi
On 12.11.2010 16:32:45 mehdi houshmand wrote:
Hi Jeremias,
This code fails the build, you need to add a ; (a semi-colon) to the
last parameter in the enumerated type in
o.a.f.fonts.truetype.TTFSubSetFile.
I don't see that. Eclipse/ECJ is happy with it and the Sun JDK 1.5.0_22
also doesn't have a problem when running the Ant build. Checking the JLS
3.0, the semicolon is optional if there's no body content after the
entries. An example from the JLS:
public class Example1 {
public enum Season { WINTER, SPRING, SUMMER, FALL }
public static void main(String[] args) {
for (Season s : Season.values()) System.out.println(s);
}
}
What environment are you working with?
I was also curious why you made
TTFSubSetFile.GlyphHandler? Why do you make it an interface, and why
do you use an anonymous class in PSFontUtils, only to pass it back to
the same class? If there's only one implementation and if it only
contains a single method, I wouldn't have thought an interface was
necessary.
It's a normal callback interface from PSFontUtils back into
TTFSubSetFile, called for each glyph when building the subset.
TTFSubSetFile already contains various methods that perform
similar functions (i.e. take an input, convert it to the necessary
format and write to file), why couldn't this be implemented in the
handleGlyphSubset(...) method?
My main problem with the way TTFSubSetFile is currently written is that
writing the records is mixed with building the table index. If that were
not so, it would have been easier to go with an approach that you would
have expected. But my approach actually has the advantage that there's
less memory build-up, since not the whole subset including glyphs has to
be buffered in memory. After all, TTF loading is known to take a LOT of
memory.
Is there another implementation you're
making this flexible for?
No. The context: my client (your employer) asked for urgent help to
resolve the problem with my first attempt at TTF subsets when printed on
HP printers. I needed a quick resolution after I found out what could be
wrong. I didn't know if I would turn out to be right until after I
committed the changes and Chris/Vincent could run tests. So I didn't
care about too much code beauty. There's actually quite a bit of
copy/paste/change in TTFSubSetFile as a result which I'm not
particularly proud of. I'm still waiting for feedback if my change
really fixed the problem although preliminary results show that the
problem is now solved. I expect that some refactoring would do
TTFSubSetFile some good.
Also, from a design point, why have you made each glyph a single
string?
That was no design decision. It's a requirement found in the PS langref
third edition, page 356, describing the contents of /GlyphDirectory.
Each glyph is looked up by its index when an array is used.
Surely if the string must finish at a glyph boundary, then we
could pack in several glyphs into the string and make it intelligent
enough not to write partial glyphs?
That would be useful if we were to keep putting the glyphs in the /sfnts
entry, but not with /GlyphDirectory.
Will this method have any performance benefits/disadvantages?
The GlyphDirectory allows to keep memory consumption down in the JavaVM.
Otherwise, I see no implications.
The spec says 65535 is the array limit, will this be hit?
I think that's unlikely. We will hardly have any font with more than
65535 glyphs and no single glyph is likely to be larger than 64KB to
describe its outline. We might still run into problems with the /sfnts
entry, though. If we can improve TTFSubSetFile it should be much easier
to stop strings at record boundaries.
snip/
Jeremias Maerki
Re: svn commit: r1035276 - /xmlgraphics/fop/trunk/test/java/org/apache/fop/fonts/EncodingModeTest.java
And mine... I'll include headers in future patches. On 16 November 2010 08:58, Simon Pepping spepp...@leverkruid.eu wrote: Oops. Sorry, sloppy work on my part. Simon On Mon, Nov 15, 2010 at 01:52:58PM -, jerem...@apache.org wrote: Author: jeremias Date: Mon Nov 15 13:52:58 2010 New Revision: 1035276 URL: http://svn.apache.org/viewvc?rev=1035276view=rev Log: Added missing license header.
Re: TrueType Font Embedding
All that being said, I could implement my initial proposal, obviously it would have to be user friendly and not conflict with the settings already available, so maybe a parameter called embedding with two possible values, full and subset (since the none is already covered by referenced fonts). As for the unique prefix for the font name, may I suggest moving it from the font level (o.a.f.fonts.MultiByteFont) to PS level (maybe implemented in somewhere like o.a.f.render.ps.PSFontUtils), this would allow a more intelligent implementation since PS and PDF don't have the same requirements in this case since PDF prefixes only need to be unique to the document. /snip
Mocking a test
Hi, I've been working on unit testing some of the classes in FOP and I think FOP could benefit from using a mocking framework. The goal is obviously that every class has a complimentary test class to test behaviour and state and mocking a class is a good way to emulate an object. I shan't make this into a lecture on the benefits, I've enclosed a good URL as to some of the benefits, but I wanted to put it to the community for feedback. This would mean including an extra JAR(s) file in the libs/ directory (obviously we'll have to be careful with licenses), but I'm just floating the idea if anyone has any preferred frameworks please do suggest pros/cons. http://martinfowler.com/articles/mocksArentStubs.html Thanks Mehdi
Re: Ant Hangs
Hi Eric, What OS are you using? If you're using Linux there are packages for installing the Ant and JUnit libraries which may avoid these issues. This I think is a config issue. Mehdi On 20 December 2010 20:28, Eric Douglas edoug...@blockhouse.com wrote: I compiled FOP 1.0 using the Ant build in Eclipse. It completed successfully saying Junit support not present. Then I downloaded the Junit source, imported it as a project, put it on the FOP Build Path, and copied the junit-4.8.2.jar into the FOP lib folder. Now the ant task shows Junit support present and the build never stops running. The last thing displayed on the Console message tab is this. junit-userconfig: [echo] Running user config tests
Re: Ant Hangs
Hi Eric,
Peters method is less hacky than mine since it means you don't
change the build.xml. Basically, you download the junit jar from and
add it to the lib folder in your ant file and that will ensure that
you can run junit with ant with any project (not just FOP). You'll
also need to add the bin folder to your PATH (if you already haven't).
Mehdi
On 21 December 2010 13:51, Eric Douglas edoug...@blockhouse.com wrote:
I put a junit jar in the fop lib directory. Without it the fop ant build
tells me junit support is not present even if I have junit in the project
build path.
I found the last message it gives me in the build file. Is it possible this
step is just taking a really long time? I'm not sure what all it's supposed
to do. I believe I left it running when I went to lunch yesterday and that
was still the last message showing when I got back.
target name=junit-userconfig depends=junit-compile if=junit.present
description=Runs FOP's user config JUnit tests
echo message=Running user config tests/
junit dir=${basedir} haltonfailure=${junit.haltonfailure}
fork=${junit.fork} errorproperty=fop.junit.error
failureproperty=fop.junit.failure
sysproperty key=basedir value=${basedir}/
sysproperty key=jawa.awt.headless value=true/
sysproperty key=fop.layoutengine.disabled
value=${layoutengine.disabled}/
sysproperty key=fop.layoutengine.testset value=standard/
formatter type=brief usefile=false/
formatter type=plain usefile=true/
formatter type=xml usefile=true/
classpath
pathelement location=${build.dir}/test-classes/
path refid=libs-run-classpath/
/classpath
test name=org.apache.fop.config.UserConfigTestSuite
todir=${junit.reports.dir} outfile=TEST-userconfig/
/junit
/target
-Original Message-
From: Peter Hancock [mailto:peter.hanc...@gmail.com]
Sent: Tuesday, December 21, 2010 6:22 AM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Ant Hangs
Hi Eric,
You can add the junit jar to Ant's lib directory - see
http://ant.apache.org/manual/install.html and look for ANT_HOME + lib
+ Windows.
I hope that helps,
Pete
On Mon, Dec 20, 2010 at 9:24 PM, mehdi houshmand med1...@gmail.com wrote:
I'm no Windows expert by any stretch of the imagination, but have you
tried adding the JUnit jar to the build XML, add the Ant jar to the
Environment variables and try running it from the command line. I
think you may have more luck there.
Mehdi
On 20 December 2010 21:12, Eric Douglas edoug...@blockhouse.com wrote:
Windows XP
-Original Message-
From: mehdi houshmand [mailto:med1...@gmail.com]
Sent: Monday, December 20, 2010 4:11 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Ant Hangs
Hi Eric,
What OS are you using? If you're using Linux there are packages for
installing the Ant and JUnit libraries which may avoid these issues.
This I think is a config issue.
Mehdi
On 20 December 2010 20:28, Eric Douglas edoug...@blockhouse.com wrote:
I compiled FOP 1.0 using the Ant build in Eclipse. It completed
successfully saying Junit support not present.
Then I downloaded the Junit source, imported it as a project, put it
on the FOP Build Path, and copied the junit-4.8.2.jar into the FOP lib
folder.
Now the ant task shows Junit support present and the build never
stops running. The last thing displayed on the Console message tab is
this.
junit-userconfig:
[echo] Running user config tests
Re: How much work is needed for FOP to support OpenType fonts?
Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams gl...@skynav.com wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: Ivan, This type of question is best put to the FOP User fop-us...@xmlgraphics.apache.org email list rather than the developer list. Actually, I was offering (or considering) to give back some of the money FOP saved me (when I self-published my book). I don't think sending my offer to the users' list would be very useful. In any
Re: How much work is needed for FOP to support OpenType fonts?
Oops, I seem to have copy/pasted that link twice, my apologies, it probably doesn't deserve 2 mentions. Mehdi On 19 January 2011 09:17, mehdi houshmand med1...@gmail.com wrote: Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams gl...@skynav.com wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. G. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: Ivan, This type of question is best put to the FOP User fop-us...@xmlgraphics.apache.org email
Re: OpenType font library [was: Re: How much work is needed for FOP to support OpenType fonts?]
Hi Simon, The FOP font library doesn't actually render or paint any fonts, it does 1 of 2 things. Either it a) creates a subset of the font, and streams the subset (as a byte stream) to the PDF/PS document or b) it streams the whole font to the document (I think this is what is done for AFP, I don't think FOP supports subset embedding in AFP). This means the reader of the document has to read the font we embed and then does all the painting and rendering. Since Firefox is a viewer/browser and doesn't have a feature to embed fonts when saving html (or at least I'm pretty sure it doesn't) I'm not sure how we could take advantage of a graphics library, since that is done in the reader and not the document. OpenGL and SDL libraries are good examples of opensource programs that do display fonts, but again, I dont think subsetting/embedding is in their scope. I could however be completely mistaken but that's my tuppence worth. Mehdi On 19 January 2011 08:35, Simon Pepping spepp...@leverkruid.eu wrote: I take this discussion to express my worries that FOP needs to create its own support for fonts, among which Open Type Fonts. FOP's core task is the layout and printing of FO files. If FOP could rely on good font libraries, that would make our code base so much smaller and our development tasks so much easier. If I am not mistaken, Firefox does a fairly good job at representing Indic scripts. Do they use a generally available library? Are there no such libraries? Or do I see the issue wrong? Regards, Simon On Tue, Jan 18, 2011 at 04:11:54PM -0700, Glenn Adams wrote: That is a better question, but one I cannot answer, as I have not looked into the CFF support issue. Perhaps another DEV would care to respond. On Tue, Jan 18, 2011 at 4:03 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 10:51 PM, Glenn Adams gl...@skynav.com wrote: On Tue, Jan 18, 2011 at 3:41 PM, Ivan Ristic ivan.ris...@gmail.com wrote: On Tue, Jan 18, 2011 at 9:27 PM, Glenn Adams gl...@skynav.com wrote: What do you mean by fully? If you are referring to the OpenType GDEF, GSUB, GPOS support, then work is already underway to add that functionality. See the following for further info: http://people.apache.org/~spepping/ http://wiki.apache.org/xmlgraphics-fop/ComplexScripts
Re: How much work is needed for FOP to support OpenType fonts?
Jeremias, They are with your /GlyphDirectory mechanism, and for full font embedding but not for subsetting with the /sfnts in my patch. And the /GlyphDirectory system was causing issues with some printers (I think IBM printers if memory serves), so it depends what you mean by supported. You'll be able to view them and print them on most printers, but can't guarantee 100% compliance. Sorry if I didn't make that clear. Mehdi On 19 January 2011 09:55, Jeremias Maerki d...@jeremias-maerki.ch wrote: Mehdi, TrueType collections are supported! On 19.01.2011 10:17:11 mehdi houshmand wrote: Hi Ivan, I've been looking quite a bit at the fonts packages recently, and you are correct neither CFF nor True Type collections are currently supported. They both need to be implemented. In terms of how long it would take, that's a very speculative question and not quite as simple to answer as it may seem. Mostly because it depends what you mean by supported? Which output format? Full font embedding or subset embedding? If you mean full font embedding, I don't think it would take very long assuming the person was familiar with the fonts packages, the FOP renderers and probably more importantly the PDF/PostScript and CFF specs. If you're not familiar with the terms I've used, full font embedding is fairly simple, it involves streaming the font byte for byte to the PDF document. In PostScript, it's a little more involved because you have to stream the font as an ASCII hexadecimal stream and break the string up (maximum size is 65535 chars) at table or glyph boundaries. Subset font embedding involves remembering which glyphs were actually used in the document and creating a subset of the font that include only those glyphs used and embedding the subset. The implications are that if you have a document with large fonts in, or a lot of different fonts, then full font embedding will bloat the file size, this may be so big that some printers (especially older ones with small memory sizes) may crash. Subset embedding does mean that you have smaller file sizes, but may cause issues if you have a print manager that holds fonts in memory for future use. I should prefix the above by saying I've only just peeked at CFF but luckily if you want full font embedding, you probably don't need to do much poking around in the CFF spec (only to get a feel of the format and what each table does), you'll need to spend more time in the PS/PDF spec. The Temp_TrueTypeInPostScript branch, has a patch associated with it, that I've been working on to support Full font and subset font embedding in the PostScript output format for TrueType fonts only, but the new architecture should make it much simpler to extend font support. So, if you mean supporting full font embedding of CFF in PostScript/PDF it shouldn't take too long. However, if you're looking for subset font embedding, this could take a bit longer (I wouldn't want to speculate on how long having not looked at the CFF spec in great detail). Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. Time wise, most of it is going to be testing since if someone was to implement support for any font features, I'd very strongly suggest JUnit testing as a starting point. The reason being that fonts are quite complicated and introducing bugs is both easy to do and difficult to root out by simply looking at the final PDF/Postscript file. The next issue is having a testbed in order to test regression and ensure that changing a method doesn't break some feature for another font format. This may sound simple, but that means creating the FOs with foreign glyphs, CJK for example, is quite laborious. If you take a look at my patch (https://issues.apache.org/bugzilla/show_bug.cgi?id=50483), I've added JUnit tests for quite a few of the classes in the fonts package so that might help you get started. If you do start implementing this feature, don't hesitate to get in contact and I can try and share some of my knowledge and/or test-suite as an when you require it. Sorry for the verbosity of the email, as you'll find, fonts are not to be underestimated. Mehdi On 18 January 2011 23:11, Glenn Adams gl
Repeated Procsets in PS
Hi Guys, I've been looking into the PS rendering, with an eye to reduce the size of PS documents. I noticed that when PS documents are created from concatenated IFs, FOP prints the procsets in a %%BeginResource: procset every time it encounters a header tag in the IF. This doesn't produce invalid PS docs or break any thing else for that matter, but appears to be completely unnecessary. I checked the DSC spec (v3 p67), and though this behaviour is allowed, it is intended so that one can print (to the document) subsets of a large procedure-set for complex graphical uses. Considering FOP is printing the same procsets every time, that intended behaviour isn't applicable in FOPs behaviour. I hacked a quick test to find out if removing these made any difference what-so-ever to documents, especially with tables with borders and embedded fonts to utilize a variety of the procedures defined in the procset. As expected, removing these superfluous proc-sets makes no difference. So, my question is thus; is that FOPs problem? This behaviour only appears to happen when someone concatenates several IFs without any intelligence to remove the header element from the IF (of which, arguably, there should only be one anyway). I checked the IF schema, and this suggests there can be zero to unbounded number of header elements, is there any real need for this? Why would you need more than one header? Is that a bug in the schema? I appreciate much of this is much over muchness but this behaviour seems counter-intuitive. Thanks for the help Mehdi P.S. If anyone wishes me to produce an example of this behaviour, I'd be more than happy to.
Re: Fonts fail to print after successive print runs that work
No problem, I didn't really do much, but if you do get to the bottom of the problem, could you post your findings and/or what you did to fix it. It just may help someone else having the same or a similar issue. Thanks Mehdi On 15 March 2011 21:59, Peter Yandell peter.yand...@truenorth3dview.com wrote: Hi Mehdi, The thought has crossed my mind that it was something to do with memory and garbage collection. Thanks for your help! Pete On 16/03/2011 5:50 AM, mehdi houshmand wrote: Hi Peter, This smells of a memory leak, I've had a few issue myself with tomcat and its funky class-loader. There are several ways you can find out whether it is a memory leak, all of which google will help you with. It was a while back, and I remember it being rather difficult to narrow it down. You'll find Fonts use up a lot of memory, and depending on your FO FOP could use up a substantial amount of memory, so leaks are really not good. That's my tuppence worth anyways, someone else out there may have seen this before. Hope that helps Mehdi On 15 March 2011 21:13, Peter Yandellpeter.yand...@truenorth3dview.com wrote: Hi Mehdi, That's right, each document is different. I also wrote a harness to continuously print two documents against our QA server. Again the fonts would disappear somewhere between 30 and 150 times. It does not appear to be a simple print X times and watch it fail which is making it very difficult to resolve. Best regards, Pete On 15/03/2011 4:09 PM, mehdi houshmand wrote: Hi Peter, You say that it can happen anywhere from the 30th document to the 150th? Does that suppose each document is different, or does the number vary if you print the same document over and over? I.e. is the number at which it fails the same over several attempts when printing a single document? Mehdi On 15 March 2011 02:12, Peter Yandellpeter.yand...@truenorth3dview.com wrote: Hi All, Background: I've recently inherited an enterprise level web application that uses FOP for generating PDF and PNG documents. These documents are printed using custom fonts. The output size is A0 (or ~ 4770 x 3370 pixels). Problem: After a variable amount of time some of the fonts 'stop working'. By this I mean that the glyph appearing is a letter 'A' in a box, with the same glyph used for all characters. Please see the two attached images; 'PrintJob-200a-47.png' rendered correctly while 'PrintJob-200a-48.png' stop working. The problem goes away after Tomcat has been restarted. Sometimes the error starts happening after 30 documents have been printed, other times it can be upwards of 150. Once it starts happening then it keeps happening until Tomcat is restarted. Resolutions Attempted: As I couldn't see any errors in our application logs I turned the FOP logging all the way up to 'ALL'. At no time were there any entries, for a 'failed' print job, that differed from a successful one. There are no WARN, ERROR or FATAL messages appearing in any log file. Searching for font issues seems to only turn up misconfigurations of fonts. All our fonts are configured correctly as the documents do print. It is simply that they are forgotten, lost, etc after some period of time with no errors or warnings recording in the logs Version numbers: JDK: 1.6.0_20 1.6.0_24 OS: Mac OSX 10.6.4 10.6.6 FOP: 0.95 1.0 Tomcat: 6.0.24 I can extract out the relevant FOP log entries for both a successful and failed run if requested. I haven't attached them as they are quite large. My request for help comes in several parts: 1. Has anyone else experienced this, and if so what did you do to resolve it? 2. Does anyone have any thoughts where else to look? I don't know where else to look right now. The web application is a commercial so I may be limited in what I can share. If anything else is required please ask and I will do my best to comply. Many thanks in advance, Pete - 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
CID Font Question
Hi Guys,
I found an issue with a True Type Font in PDF, I have attached a PDF
with the possible bug (buggy.pdf) and with my fix (fixed.pdf). The
issue is that if you copy/paste the text from the normal-weighted font
(top line) of the PDF, the (space) and ! (exclamation mark)
characters are mapped to unicode index \u.
Initially I thought this was a bug in the font, so I looked at the
cmap table in the font to see what unicode index these glyphs were
mapped to, and I found that they were the 2nd and 3rd entries in the
cmap table. This tickled my curiosity because all the fonts I
remember (and I checked a couple to be sure) have the first 3 glyphs
mapped to \u or \u and in their CID is .notdef. The BOLD
version of the same font (in both PDFs) works fine, and as expected
the first 3 glyphs are mapped to \u, \u and \u
respectively.
I also checked the code-base and in o.a.f.fonts.CIDSubset has the
following lines of code:
/**
* Adds the initial 3 glyphs which are the same for all CID subsets.
*/
public void setupFirstThreeGlyphs() {
// Make sure that the 3 first glyphs are included
usedGlyphs.put(new Integer(0), new Integer(0));
usedGlyphsIndex.put(new Integer(0), new Integer(0));
usedGlyphsCount++;
usedGlyphs.put(new Integer(1), new Integer(1));
usedGlyphsIndex.put(new Integer(1), new Integer(1));
usedGlyphsCount++;
usedGlyphs.put(new Integer(2), new Integer(2));
usedGlyphsIndex.put(new Integer(2), new Integer(2));
usedGlyphsCount++;
}
So I checked the specification and no where does it suggest that the
first THREE are reserved, it does however say that CID 0 should be
.notdef. (see quote below, p340 of PDF spec).
Every CIDFont must contain a glyph description for CID 0, which is
analogous to the .notdef character name in simple fonts (see “Handling
Undefined Characters” on page 355).
My question is this, is this a FOP bug or is this a bug in the font
we're using? If it's a fop bug, I'd be more than happy to fix it
(delete the 6 lines and change the method name). If, however, it's a
font bug, then which spec should I be looking at? What is the bug? I
should also mention, that I started with the TTF spec and this doesn't
suggest that any glyphs are reserved.
Any help on this would very much be appreciated,
Mehdi
fixed.pdf
Description: Adobe PDF document
buggy.pdf
Description: Adobe PDF document
Re: CID Font Question
Excellent. I looked back and tracked it back to the same commit, and
as you can imagine, perplexing me further.
Well I'll post a fix soon.
Mehdi
On 18 March 2011 14:59, Jeremias Maerki d...@jeremias-maerki.ch wrote:
Hi Mehdi
Interesting problem. Apparently, the overwhelming majority of TrueType
fonts map glyph index 1 to .null and glyph index 2 to nonmarkingreturn
(for carriage returns and such). Your version of the Frutiger 45 Light
font apparently doesn't but has space on glyph index 1.
Those three blind indices have been in FOP's codebase since the
addition of CID subsets in 2001:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/org/apache/fop/render/pdf/fonts/MultiByteFont.java?r1=194167r2=194168pathrev=195822;
Funny that something like this shows up after so much time.
Anyway, since we only need to embed a .notdef as index 0 and the glyphs
we really need I think it is safe to remove the fixed indices 1 and
2 since this whole thing then seems to work for both kinds of fonts.
I'd say, put your patch in Bugzilla!
On 17.03.2011 17:27:22 mehdi houshmand wrote:
Hi Guys,
I found an issue with a True Type Font in PDF, I have attached a PDF
with the possible bug (buggy.pdf) and with my fix (fixed.pdf). The
issue is that if you copy/paste the text from the normal-weighted font
(top line) of the PDF, the (space) and ! (exclamation mark)
characters are mapped to unicode index \u.
Initially I thought this was a bug in the font, so I looked at the
cmap table in the font to see what unicode index these glyphs were
mapped to, and I found that they were the 2nd and 3rd entries in the
cmap table. This tickled my curiosity because all the fonts I
remember (and I checked a couple to be sure) have the first 3 glyphs
mapped to \u or \u and in their CID is .notdef. The BOLD
version of the same font (in both PDFs) works fine, and as expected
the first 3 glyphs are mapped to \u, \u and \u
respectively.
I also checked the code-base and in o.a.f.fonts.CIDSubset has the
following lines of code:
/**
* Adds the initial 3 glyphs which are the same for all CID subsets.
*/
public void setupFirstThreeGlyphs() {
// Make sure that the 3 first glyphs are included
usedGlyphs.put(new Integer(0), new Integer(0));
usedGlyphsIndex.put(new Integer(0), new Integer(0));
usedGlyphsCount++;
usedGlyphs.put(new Integer(1), new Integer(1));
usedGlyphsIndex.put(new Integer(1), new Integer(1));
usedGlyphsCount++;
usedGlyphs.put(new Integer(2), new Integer(2));
usedGlyphsIndex.put(new Integer(2), new Integer(2));
usedGlyphsCount++;
}
So I checked the specification and no where does it suggest that the
first THREE are reserved, it does however say that CID 0 should be
.notdef. (see quote below, p340 of PDF spec).
Every CIDFont must contain a glyph description for CID 0, which is
analogous to the .notdef character name in simple fonts (see “Handling
Undefined Characters” on page 355).
My question is this, is this a FOP bug or is this a bug in the font
we're using? If it's a fop bug, I'd be more than happy to fix it
(delete the 6 lines and change the method name). If, however, it's a
font bug, then which spec should I be looking at? What is the bug? I
should also mention, that I started with the TTF spec and this doesn't
suggest that any glyphs are reserved.
Any help on this would very much be appreciated,
Mehdi
Jeremias Maerki
Re: not letting me put xsl:tempate inside fo:root
I agree, it seems you may have misunderstood the purpose and/or function of an xsl:template element, I think it may be worth going through some XSLT tutorials to get a better understanding of how to XSL templates. Mehdi On 4 May 2011 20:16, J.Pietschmann j3322...@yahoo.de wrote: On 04.05.2011 20:15, Brian wrote: Are we not allowed to put xsl:template inside fo:root? No. According to the XSLT spec, xsl:template must be an immediate child of xsl:stylesheet, see http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-stylesheet and other parts of the spec. Outside fo:root it works fine, but this doesn't help me in this particular scenerio. The xsl:template element is a declaration, so your statement makes me think you are seriously confused about how XSLT works. The best way to clean this up is usually to send a problem description to the XSL list, where the gurus tend to hang out. Guidelines and subscription advice here: http://www.mulberrytech.com/xsl/xsl-list/ J.Pietschmann
Re: not letting me put xsl:tempate inside fo:root
Sorry, how to *use* XSL templates. On 5 May 2011 09:01, mehdi houshmand med1...@gmail.com wrote: I agree, it seems you may have misunderstood the purpose and/or function of an xsl:template element, I think it may be worth going through some XSLT tutorials to get a better understanding of how to XSL templates. Mehdi On 4 May 2011 20:16, J.Pietschmann j3322...@yahoo.de wrote: On 04.05.2011 20:15, Brian wrote: Are we not allowed to put xsl:template inside fo:root? No. According to the XSLT spec, xsl:template must be an immediate child of xsl:stylesheet, see http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-stylesheet and other parts of the spec. Outside fo:root it works fine, but this doesn't help me in this particular scenerio. The xsl:template element is a declaration, so your statement makes me think you are seriously confused about how XSLT works. The best way to clean this up is usually to send a problem description to the XSL list, where the gurus tend to hang out. Guidelines and subscription advice here: http://www.mulberrytech.com/xsl/xsl-list/ J.Pietschmann
AFP Character set naming conventions
Hi, Prologue: I am investigating an AFP issue, and one of our AFP printers rejected the document with an error in the MCF (Map Coded Font) entry for the character set not being found. Nothing unusual for AFP, however, I hadn't given FOP a fop.xconf, so no custom fonts are being defined. Anyway, after a bit of investigation, and a discussion with a colleague, it became apparent that there could be a typo in the AFP Base 12 fonts. Problem: In the AFP doc, it said the character was called CON40090, so I checked the AFP naming convention (I'm sure I've seen it in one of the specs, but the link is below). Notice the second character is O (letter) not 0 (number) which is contrary to the naming convention. This could be a typo, or it could quite easily be a misinterpretation of the spec on my part, since there are a bazillion different documents on AFP fonts, I could have easily missed something somewhere. The issue, is only with TimesNewRoman in o.a.f.afp.fonts.AFPBase12FontCollection.java, I looked around to see if any other fonts have this same issue and none seem to. Is this a bug? Am I missing something? If it's a bug, I'll happily provide a patch. link: http://www4.infoprintsolutionscompany.com/help/index.jsp?topic=/com.ibm.printers.afpproducts/com.ibm.printers.guidetooutput/c5pu3mst49.htm Thanks Mehdi
Re: AFP Character set naming conventions
Sorry for the late reply, I've posted a patch to resolve this issue. https://issues.apache.org/bugzilla/show_bug.cgi?id=51205 On 16 May 2011 10:20, Jeremias Maerki d...@jeremias-maerki.ch wrote: Hi Mehdi Looks like a typo to me. See: http://www4.infoprintsolutionscompany.com/help/topic/com.ibm.printers.afpproducts/com.ibm.printers.guidetooutput/c5pu3mst49.htm C0 (C - zero) designates a raster character set. So, CO (C - O) would be wrong. On 16.05.2011 10:40:00 mehdi houshmand wrote: Hi, Prologue: I am investigating an AFP issue, and one of our AFP printers rejected the document with an error in the MCF (Map Coded Font) entry for the character set not being found. Nothing unusual for AFP, however, I hadn't given FOP a fop.xconf, so no custom fonts are being defined. Anyway, after a bit of investigation, and a discussion with a colleague, it became apparent that there could be a typo in the AFP Base 12 fonts. Problem: In the AFP doc, it said the character was called CON40090, so I checked the AFP naming convention (I'm sure I've seen it in one of the specs, but the link is below). Notice the second character is O (letter) not 0 (number) which is contrary to the naming convention. This could be a typo, or it could quite easily be a misinterpretation of the spec on my part, since there are a bazillion different documents on AFP fonts, I could have easily missed something somewhere. The issue, is only with TimesNewRoman in o.a.f.afp.fonts.AFPBase12FontCollection.java, I looked around to see if any other fonts have this same issue and none seem to. Is this a bug? Am I missing something? If it's a bug, I'll happily provide a patch. link: http://www4.infoprintsolutionscompany.com/help/index.jsp?topic=/com.ibm.printers.afpproducts/com.ibm.printers.guidetooutput/c5pu3mst49.htm Thanks Mehdi Jeremias Maerki
Re: svn commit: r1144351 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
Hi Jeremias,
Just to satiate your curiousity, in the modca spec, page 96, it says
A medium map remains in effect until another medium map is selected
or the end of the document is reached., which means the previous
implementation, storing the lastMediumMap, would be perfectly valid.
Mehdi
On 8 July 2011 16:00, jerem...@apache.org wrote:
Author: jeremias
Date: Fri Jul 8 15:00:47 2011
New Revision: 1144351
URL: http://svn.apache.org/viewvc?rev=1144351view=rev
Log:
Removed the lastMediumMap variable and the check to omit the IMM if it
doesn't change. I wonder why I came up with that. This can lead, among other
things, to problems when an AFP file is split.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java?rev=1144351r1=1144350r2=1144351view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
Fri Jul 8 15:00:47 2011
@@ -83,9 +83,6 @@ public class AFPDocumentHandler extends
private MapString, PageSegmentDescriptor pageSegmentMap
= new java.util.HashMapString, PageSegmentDescriptor();
- /** Medium Map referenced on previous page **/
- private String lastMediumMap;
-
private static enum Location {
ELSEWHERE, IN_DOCUMENT_HEADER, FOLLOWING_PAGE_SEQUENCE, IN_PAGE_HEADER
}
@@ -379,9 +376,8 @@ public class AFPDocumentHandler extends
}
AFPInvokeMediumMap imm = (AFPInvokeMediumMap)extension;
String mediumMap = imm.getName();
- if (mediumMap != null !mediumMap.equals(lastMediumMap)) {
+ if (mediumMap != null) {
dataStream.createInvokeMediumMap(mediumMap);
- lastMediumMap = mediumMap;
}
} else if (extension instanceof AFPIncludeFormMap) {
AFPIncludeFormMap formMap = (AFPIncludeFormMap)extension;
-
To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
Re: svn commit: r1144351 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
Hi Jeremias,
Yes, I agree, I wasn't trying to make a point, or even contest the
commit. You said in the commit message that you weren't sure why you
did that originally, I just wanted to illustrate why. Both ways make
sense.
Mehdi
On 12 July 2011 10:40, Jeremias Maerki d...@jeremias-maerki.ch wrote:
Hi Mehdi
Sure, but imagine someone cuts an AFP appart at some page group boundary
to make smaller print streams. The second part might not contain the IMM
instruction and might therefore end up printed wrong. The splitter would
have to have the intelligence to scan the whole AFP and insert new IMMs
during the split. I think it's safer this way.
On 12.07.2011 11:12:27 mehdi houshmand wrote:
Hi Jeremias,
Just to satiate your curiousity, in the modca spec, page 96, it says
A medium map remains in effect until another medium map is selected
or the end of the document is reached., which means the previous
implementation, storing the lastMediumMap, would be perfectly valid.
Mehdi
On 8 July 2011 16:00, jerem...@apache.org wrote:
Author: jeremias
Date: Fri Jul 8 15:00:47 2011
New Revision: 1144351
URL: http://svn.apache.org/viewvc?rev=1144351view=rev
Log:
Removed the lastMediumMap variable and the check to omit the IMM if it
doesn't change. I wonder why I came up with that. This can lead, among
other things, to problems when an AFP file is split.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java?rev=1144351r1=1144350r2=1144351view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/afp/AFPDocumentHandler.java
Fri Jul 8 15:00:47 2011
@@ -83,9 +83,6 @@ public class AFPDocumentHandler extends
private MapString, PageSegmentDescriptor pageSegmentMap
= new java.util.HashMapString, PageSegmentDescriptor();
- /** Medium Map referenced on previous page **/
- private String lastMediumMap;
-
private static enum Location {
ELSEWHERE, IN_DOCUMENT_HEADER, FOLLOWING_PAGE_SEQUENCE,
IN_PAGE_HEADER
}
@@ -379,9 +376,8 @@ public class AFPDocumentHandler extends
}
AFPInvokeMediumMap imm = (AFPInvokeMediumMap)extension;
String mediumMap = imm.getName();
- if (mediumMap != null !mediumMap.equals(lastMediumMap)) {
+ if (mediumMap != null) {
dataStream.createInvokeMediumMap(mediumMap);
- lastMediumMap = mediumMap;
}
} else if (extension instanceof AFPIncludeFormMap) {
AFPIncludeFormMap formMap = (AFPIncludeFormMap)extension;
-
To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
Jeremias Maerki
Re: Which came first, the chicken or the egg?
Hi Eric, What operating system are you working on? You probably don't need to compile ant, there will almost definitely be binaries for your operating system. Mehdi On 19 July 2011 13:58, Eric Douglas edoug...@blockhouse.com wrote: If I try to compile fop source it says it requires ant. If I download the source for ant and try to compile it says it requires bsf. If I download the source for bsf and try to compile it says it requires jython. If I download the source for jython and try to compile it says it requires ant.
Re: Which came first, the chicken or the egg?
You'll find it here: http://ant.apache.org/bindownload.cgi On 19 July 2011 14:07, mehdi houshmand med1...@gmail.com wrote: Hi Eric, What operating system are you working on? You probably don't need to compile ant, there will almost definitely be binaries for your operating system. Mehdi On 19 July 2011 13:58, Eric Douglas edoug...@blockhouse.com wrote: If I try to compile fop source it says it requires ant. If I download the source for ant and try to compile it says it requires bsf. If I download the source for bsf and try to compile it says it requires jython. If I download the source for jython and try to compile it says it requires ant.
Re: should complex script features be enabled or disabled by default?
Hi Glenn, We took a look at the complex scripts support, and a big chunk of the code-base is in the fonts, and the layout tests don't cover fonts, rendering etc. What are you finding for end-to-end performance? We created a large latin only document and found about 50% increase in time. Mehdi On 19 July 2011 14:36, Glenn Adams gl...@skynav.com wrote: Taking the average of the best 3 out of 5 runs for a couple of the junit tests, I get the following: TRUNK CMPLX DIFF% junit-basic 4.87s 4.92s 1.01% junit-layout-standard 36.34s 36.72s 1.04% In the case of junit-layout-standard, there are 25 more tests run in the Complex Script branch. So, I'd say that there is about a 1% decrease in speed performance based on this data. I doubt if users will even notice this, so this would argue for enabling by default. On Tue, Jul 19, 2011 at 2:08 AM, Pascal Sancho pascal.san...@takoma.fr wrote: Hi Glenn, IMHO, the default setting should depend on how much it affects the performances. Can you give an approximative impact? Le 19/07/2011 03:40, Glenn Adams a écrit : I'm adding a feature to allow enable/disable of complex script features (bidi, complex char to glyph mapping) at runtime, using either (or both) command line option and config file element; the question I have is whether to enable or disable by default? If enabled by default, those who don't use complex scripts or don't want advanced typography features in non-complex scripts will incur a minor performance penalty. If disabled by default, then those users who use complex scripts or want advanced typography features in non-complex scripts will need to do something special to enable this support. What does the group think? I don't have a strong preference either way. G. -- Pascal
Re: should complex script features be enabled or disabled by default?
Hi Glenn, What we did isn't very complex, a 2000-odd page document filled with Loret ipsum... That's about it, the font used was ArialUnicodeMS.ttf and was embedded in the PDF. The version was i18n.arabic@09c38b8b and the major blocking point was in TTFFile.java readGDEF(in) readGSUB(in) and readGPOS(in). Commenting these out reduced the performance impact from 150% to 110% as compared to trunk. Mehdi On 19 July 2011 15:02, Glenn Adams gl...@skynav.com wrote: I'm not sure what you mean by the layout tests don't cover fonts, rendering. While it is true that those tests do not cover rendering, it does include use of fonts. Could you send me the large latin only document in FO form (preferably compressed if large), so I may test it? G. On Tue, Jul 19, 2011 at 7:51 AM, mehdi houshmand med1...@gmail.com wrote: Hi Glenn, We took a look at the complex scripts support, and a big chunk of the code-base is in the fonts, and the layout tests don't cover fonts, rendering etc. What are you finding for end-to-end performance? We created a large latin only document and found about 50% increase in time. Mehdi On 19 July 2011 14:36, Glenn Adams gl...@skynav.com wrote: Taking the average of the best 3 out of 5 runs for a couple of the junit tests, I get the following: TRUNK CMPLX DIFF% junit-basic 4.87s 4.92s 1.01% junit-layout-standard 36.34s 36.72s 1.04% In the case of junit-layout-standard, there are 25 more tests run in the Complex Script branch. So, I'd say that there is about a 1% decrease in speed performance based on this data. I doubt if users will even notice this, so this would argue for enabling by default. On Tue, Jul 19, 2011 at 2:08 AM, Pascal Sancho pascal.san...@takoma.fr wrote: Hi Glenn, IMHO, the default setting should depend on how much it affects the performances. Can you give an approximative impact? Le 19/07/2011 03:40, Glenn Adams a écrit : I'm adding a feature to allow enable/disable of complex script features (bidi, complex char to glyph mapping) at runtime, using either (or both) command line option and config file element; the question I have is whether to enable or disable by default? If enabled by default, those who don't use complex scripts or don't want advanced typography features in non-complex scripts will incur a minor performance penalty. If disabled by default, then those users who use complex scripts or want advanced typography features in non-complex scripts will need to do something special to enable this support. What does the group think? I don't have a strong preference either way. G. -- Pascal
Re: Which came first, the chicken or the egg?
One of the many beauties of linux is the repositories handle these things for you. But basically you need to use ant directly, you don't need to compile it, it can be done from the command prompt, you just need to put ant in the environment variables %PATH%, instructions can be found here: http://ant.apache.org/manual/install.html I'd just install Cygwin and save myself the hassle of dealing with the command prompt in Windows, but then you maybe more Windows literate than me. Mehdi On 19 July 2011 15:38, Eric Douglas edoug...@blockhouse.com wrote: The circular referencing doesn't make sense, but I'm compiling in Eclipse Helios on Windows XP. I found that Eclipse does come with an ant folder under it's plugin path so I started with the ant.jar from there. -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Tuesday, July 19, 2011 9:08 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Which came first, the chicken or the egg? Hi Eric, What operating system are you working on? You probably don't need to compile ant, there will almost definitely be binaries for your operating system. Mehdi On 19 July 2011 13:58, Eric Douglas edoug...@blockhouse.com wrote: If I try to compile fop source it says it requires ant. If I download the source for ant and try to compile it says it requires bsf. If I download the source for bsf and try to compile it says it requires jython. If I download the source for jython and try to compile it says it requires ant.
Re: Which came first, the chicken or the egg?
Hi Eric, Well, that kind of depends on how you work. It's always good to have the source at hand if you want to look, but realistically, you're never going to delve into the ant code. If you want further help, could you post on the ant forums, this isn't a FOP issue. Sorry if not helped, Mehdi On 19 July 2011 16:09, Eric Douglas edoug...@blockhouse.com wrote: I've tried to reference a source project rather than a compiled jar wherever possible. The annoying part of referencing the compiled jar is when I run from the IDE in debug mode and it pops up windows saying no code attached. Plus I thought it made more sense to have the source for everything open sourced in case there's any reusable code or any confusion on what the methods do. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Tuesday, July 19, 2011 10:49 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Which came first, the chicken or the egg? Eric, Unless you are working on Gentoo Linux, you should not even consider this path. Just download ant. Ant, being a build tool, has a complex bootstrap process. ant.apache.org will provide you with a zip file with a perfectly working copy of Ant you can use. On Tue, Jul 19, 2011 at 10:38 AM, Eric Douglas edoug...@blockhouse.com wrote: The circular referencing doesn't make sense, but I'm compiling in Eclipse Helios on Windows XP. I found that Eclipse does come with an ant folder under it's plugin path so I started with the ant.jar from there. -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Tuesday, July 19, 2011 9:08 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Which came first, the chicken or the egg? Hi Eric, What operating system are you working on? You probably don't need to compile ant, there will almost definitely be binaries for your operating system. Mehdi On 19 July 2011 13:58, Eric Douglas edoug...@blockhouse.com wrote: If I try to compile fop source it says it requires ant. If I download the source for ant and try to compile it says it requires bsf. If I download the source for bsf and try to compile it says it requires jython. If I download the source for jython and try to compile it says it requires ant.
Fop's build process
Hi Guys, I want to propose an upgrade of our test system to JUnit 4, the benefits of upgrading can be found on plenty of blogs [1], but I just wanted to get a feel of what everyone thought? For those that aren't familiar with JUnit 4, it is backward compatible, so that may alleviate some migration worries. [1] http://weblogs.java.net/blog/fabianocruz/archive/2006/06/junit_4_you.html Mehdi
Re: Fop's build process
Hi Guys, Since there's been overwhelming support for this, I'll throw another thought out there for people to consider. While looking at these tests, it seems logical to me to change the way FOP invokes the JUnit tests, so that rather than invoking test-suites, the build.xml, invokes ALL classes that match the regex *TestCase.java. The benefit of this would be that if someone forgets to add a unit test to a test suite, the test is still invoked, but more importantly, it would greatly simplify the build.xml. This would also mean that the layout/area tree/IF test-suites will have to change to take advantage of the JUnit4 parametrised test system. But that's not difficult to do, and quite frankly I don't like that they depend on so many obscure system parameters, I appreciate that that's the only way to parametrise tests in JUnit3, but this gives us an opportunity to improve it. This also has the added benefit that people can run these tests in their IDE without having to inject system parameters. I welcome any thoughts on this, I have not have appreciated all the use cases. I also intend on leaving the test-suites that are already there, so that should people want to invoke these tests, they can. Mehdi On 14 September 2011 10:36, Peter Hancock peter.hanc...@gmail.com wrote: Thanks Mehdi for considering this, thats a +1 from me. This will require some work. A quick search on the subject of 3 to 4 migration yielded quite a few guides that pointed out some pitfalls. A general recommendation, for instance, is not to mix JUnit 3 and 4 conventions, e.g. est classes should not extend TestCase as this will instruct the framework to adopt JUnit 3 behavior. Unfortunately I could not find a defacto migration guide on the JUnit site, and I have no good reason to link to any other guide without evaluating in detail. If another member of our community has made the transition on another project and can offer advice, or perhaps can I point us to useful resources, this would be most welcomed! Thanks, Peter On Wed, Sep 14, 2011 at 10:16 AM, mehdi houshmand med1...@gmail.com wrote: Hi Guys, I want to propose an upgrade of our test system to JUnit 4, the benefits of upgrading can be found on plenty of blogs [1], but I just wanted to get a feel of what everyone thought? For those that aren't familiar with JUnit 4, it is backward compatible, so that may alleviate some migration worries. [1] http://weblogs.java.net/blog/fabianocruz/archive/2006/06/junit_4_you.html Mehdi
Re: Revision 1175754 introduces a findbugs error
Hi Simon, Well, obviously a unit test would be the ideal solution here, but alas... Funnily, I just checked and the method signature is correct on our branch, just a silly merge error. There is another way to ensure this doesn't happen again, by prefixing all overriding methods with @Override. This way the compiler will throw an error if said method doesn't actually override any super class. Mehdi On 29 September 2011 09:20, Simon Pepping spepp...@leverkruid.eu wrote: I will fix it. It is a good habit to run findbugs. This error means that CIDFont.getDefaultWidth() is not overwritten in MultiByteFont, and that therefore MultiByteFont.getDefaultWidth() returns the wrong value. Can there be a test that reveals such an error? Simon On Wed, Sep 28, 2011 at 08:53:26PM +0100, mehdi houshmand wrote: Hi, This is my fault, I think this was a merge conflict here, it should be MultiByteFont.getDefaultWidth(). My apologies. Mehdi On 28 September 2011 20:38, Simon Pepping spepp...@leverkruid.eu wrote: Revision 1175754 introduces a significant findbugs error: VERY confusing to have methods org.apache.fop.fonts.MultiByteFont.getdefaultwidth() and org.apache.fop.fonts.CIDFont.getDefaultWidth() Simon
Re: Where's the class?
Sorry Eric, I meant to say, this is a developer question, could you post questions concerning the code on fop-dev in future. Thanks Mehdi On 19 October 2011 14:47, mehdi houshmand med1...@gmail.com wrote: Hi Eric, The renderers of old were removed quite a while ago in commit#989178. Hope that helps Mehdi On 19 October 2011 14:33, Eric Douglas edoug...@blockhouse.com wrote: I downloaded fop as the latest trunk snapshot and it says you took away a class? What happened to org.apache.fop.render.pdf.PDFRenderer?
Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
Hi Eric, Could you put up which unit tests are failing. Another user is having a similar issue. Thanks Mehdi On 24 October 2011 14:05, Eric Douglas edoug...@blockhouse.com wrote: Sounds like just what I was looking for! Thanks! I used the TortoiseSVN to download the trunk but I still haven't figured out how to compile it with ant. It keeps saying it failed at least one junit test. I did just do File Export in Eclipse, selecting all class files and got a working jar. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Monday, October 24, 2011 8:46 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size? Here you go: http://svn.apache.org/viewvc?rev=1188123view=rev In addition to nextPage(), there is now also a nextPage(width, height) for changing the size of the following pages. On 24.10.2011 14:29:23 Eric Douglas wrote: It appears the only place it sets the page size is in the setupDocument method which also writes the characters to initialize the PDF. I want to be able to put a portrait page and a landscape page in the same document, which sort of works if I call that method but it has those extra characters which messes up the text though the pages are turned correctly. Jeremias Maerki
Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
Curious... The other user was complaining of the same issue... Anyone got any ideas? I can't recreate this. On 24 October 2011 19:20, Eric Douglas edoug...@blockhouse.com wrote: I don't know. After several failed builds and changing to make errors go away now I get this... Failures: 0, Errors: 0 after every test Only error message I see is [junit] Oct 24, 2011 1:56:01 PM org.apache.fop.apps.FopFactory resolveURI [junit] SEVERE: Attempt to resolve URI 'badprotocol:test/resources/fonts/glb12.ttf.xml' failed: [junit] javax.xml.transform.TransformerException: Error with URL; base 'file:/C:/Java/fop-trunk/trunk/test/config/' href 'badprotocol:test/resources/fonts/glb12.ttf.xml' Then it ends with BUILD FAILED C:\Java\fop-trunk\trunk\build.xml:875: NOTE: ** * One or more of the Junit tests had Failures or Errors or were skipped! * * Please check the output above for relevant messages. * * Or use the junit-reports target to generate HTML test reports. * ** -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Monday, October 24, 2011 9:28 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size? Hi Eric, Could you put up which unit tests are failing. Another user is having a similar issue. Thanks Mehdi On 24 October 2011 14:05, Eric Douglas edoug...@blockhouse.com wrote: Sounds like just what I was looking for! Thanks! I used the TortoiseSVN to download the trunk but I still haven't figured out how to compile it with ant. It keeps saying it failed at least one junit test. I did just do File Export in Eclipse, selecting all class files and got a working jar. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Monday, October 24, 2011 8:46 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size? Here you go: http://svn.apache.org/viewvc?rev=1188123view=rev In addition to nextPage(), there is now also a nextPage(width, height) for changing the size of the following pages. On 24.10.2011 14:29:23 Eric Douglas wrote: It appears the only place it sets the page size is in the setupDocument method which also writes the characters to initialize the PDF. I want to be able to put a portrait page and a landscape page in the same document, which sort of works if I call that method but it has those extra characters which messes up the text though the pages are turned correctly. Jeremias Maerki
Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size?
Ok well that's at least a little bit related, you need Hyphenation support in order to run all of the unit tests, which you can find here: http://offo.sourceforge.net/ It was put there for licensing reasons. On 24 October 2011 20:47, Eric Douglas edoug...@blockhouse.com wrote: Of course it doesn't say there were any errors. The error message says one or more...errors or were skipped I saved the build log. While it doesn't mention any errors aside from that URI, it does have this near the top: compile-hyphenation: [echo] Hyphenation successful Then this near the bottom: hyphenation-present: [echo] Hyphenation Support NOT Present - Layout tests which require hyphenation are NOT being run! Is that related? The only other reference to skip is this: [junit] WARNING: Skipping malformed value for font-family: 'Times New 'Roman in 'Times New 'Roman, serif. -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Monday, October 24, 2011 3:38 PM To: fop-dev@xmlgraphics.apache.org Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size? Curious... The other user was complaining of the same issue... Anyone got any ideas? I can't recreate this. On 24 October 2011 19:20, Eric Douglas edoug...@blockhouse.com wrote: I don't know. After several failed builds and changing to make errors go away now I get this... Failures: 0, Errors: 0 after every test Only error message I see is [junit] Oct 24, 2011 1:56:01 PM org.apache.fop.apps.FopFactory resolveURI [junit] SEVERE: Attempt to resolve URI 'badprotocol:test/resources/fonts/glb12.ttf.xml' failed: [junit] javax.xml.transform.TransformerException: Error with URL; base 'file:/C:/Java/fop-trunk/trunk/test/config/' href 'badprotocol:test/resources/fonts/glb12.ttf.xml' Then it ends with BUILD FAILED C:\Java\fop-trunk\trunk\build.xml:875: NOTE: ** * One or more of the Junit tests had Failures or Errors or were skipped! * * Please check the output above for relevant messages. * * Or use the junit-reports target to generate HTML test reports. * ** -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Monday, October 24, 2011 9:28 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size? Hi Eric, Could you put up which unit tests are failing. Another user is having a similar issue. Thanks Mehdi On 24 October 2011 14:05, Eric Douglas edoug...@blockhouse.com wrote: Sounds like just what I was looking for! Thanks! I used the TortoiseSVN to download the trunk but I still haven't figured out how to compile it with ant. It keeps saying it failed at least one junit test. I did just do File Export in Eclipse, selecting all class files and got a working jar. -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Monday, October 24, 2011 8:46 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: org.apache.fop.svg.PDFDocumentGraphics2D can't change page size? Here you go: http://svn.apache.org/viewvc?rev=1188123view=rev In addition to nextPage(), there is now also a nextPage(width, height) for changing the size of the following pages. On 24.10.2011 14:29:23 Eric Douglas wrote: It appears the only place it sets the page size is in the setupDocument method which also writes the characters to initialize the PDF. I want to be able to put a portrait page and a landscape page in the same document, which sort of works if I call that method but it has those extra characters which messes up the text though the pages are turned correctly. Jeremias Maerki
Re: [VOTE SUMMARY] Mehdi Houshmand for FOP committer
Hi Chris, mehdi isn't taken, so if you could set me up with that ID. Thank you all for your positive messages, I'll endeavour to ensure FOP remains the high quality product you have developed. Mehdi On 16 November 2011 09:35, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 10/11/2011 14:18, Chris Bowditch wrote: Dear FOP committers, The vote has been running for 6 days now so it's time to sum up the votes. Mehdi has submitted dozens of high quality patches and regularly participates on the mailing lists. Mehdi is already an official FOP Contributor. I propose Mehdi Houshmand as a FOP committer. I vote +1 There were 6 +1s, no 0's or vetos, so the vote passes. Congratulations Mehdi on becoming a committer. Please send me your preferred login ID so I can create your account. The following page will help with the task of making sure you pick a unique ID: http://people.apache.org/committer-index.html Thanks, Chris Replies to general@ please. Thanks, Chris
Re: insufficient output from LayoutEngineTestCase failures
Hi Glenn, Yeah, JUnit4 doesn't allow one to parametrize test names this is a known issue. I did spend some time looking into how it would be possible, see https://issues.apache.org/bugzilla/show_bug.cgi?id=51928. Hopefully it will be rectified soon. Mehdi On 16 November 2011 23:47, Glenn Adams gl...@skynav.com wrote: With the recent transition to JUnit4 runner and changes to LayoutEngineTestCase, it is now someone difficult to determine (from output data alone) which layoutengine test file failed when a regression occurs. In particular, the exception trace generated from EvalCheck, TrueCheck, etc. does not include the test case input file name. So one ends up with something like the following in the TEST-org.apache.fop.layoutengine.LayoutEngineTestCase.txt file in builds/test-reports: Testcase: runTest[342] took 0.017 sec Caused an ERROR Expected XPath expression to evaluate to '2', but got '' (XPath: //pageViewport[@nr=1]/page/regionViewport/regionBody/mainReference/span/flow/block/lineArea/inlineparent/text) java.lang.RuntimeException: Expected XPath expression to evaluate to '2', but got '' (XPath: //pageViewport[@nr=1]/page/regionViewport/regionBody/mainReference/span/flow/block/lineArea/inlineparent/tex\ t) at org.apache.fop.layoutengine.EvalCheck.doCheck(EvalCheck.java:86) at org.apache.fop.layoutengine.EvalCheck.check(EvalCheck.java:60) at org.apache.fop.layoutengine.LayoutEngineTestCase.doATChecks(LayoutEngineTestCase.java:258) at org.apache.fop.layoutengine.LayoutEngineTestCase.checkAll(LayoutEngineTestCase.java:191) at org.apache.fop.layoutengine.LayoutEngineTestCase.runTest(LayoutEngineTestCase.java:172) Testcase: runTest[343] took 0.012 sec Unfortunately, there is no way to correlate runTest[342] with a specific test case input file. It would be very useful (for AT and IF tests) to also include the test case input file name/path in this output. Otherwise, one is forced to run junit in a debugger with a breakpoint on EvalCheck, TrueCheck, etc.
Re: Documentation of new testing tools
Hi Simon, My apologies, I did float the idea about the layout engine tests and kept to the suggestions that were given me. As such, creating tests is exactly the same and the subset of tests run are still configurable via System properties. The behaviour is the same, the only difference made is in the implementation. As for JUnit4 and Jacoco, these are primarily for developers and I'm not sure what you wish to see documented? What would we document that isn't repeating information readily available elsewhere? If you have questions, I'd be more than happy to answer them, but below I've included a couple informative links: Here is a good introduction to Junit4: http://www.ibm.com/developerworks/java/library/j-junit4/index.html This is a fairly good analysis of Jacoco listing pros and cons, by the people at Eclipse: http://wiki.eclipse.org/JaCoCo/Proposal There are plenty of other code-coverage tools, but I chose Jacoco for predominantly a single feature: It can be used to analyse code coverage of integration (end-to-end) tests. This would provide valuable stats for assessing the testing framework. http://www.eclemma.org/jacoco/trunk/doc/agent.html Hope that helps Mehdi On 18 November 2011 18:42, Simon Pepping spepp...@leverkruid.eu wrote: Mehdi has recommended himself to the FOP team by taking new initiatives, such as Junit4 and Jacoco. But where is the documentation? See e.g. the wiki page HowToCreateLayoutEngineTests: Does that still apply? How do I know what jacoco is and how to run it? Should I just be in the know? Please, consider adding and updating documentation of new and renewed build and test tools. Simon
Re: Documentation of new testing tools
Hi, I've hopefully provided enough information at the link below, if I've missed anything, I'd be happy to amend the wiki page. http://wiki.apache.org/xmlgraphics-fop/HowTo/CreateUnitTests Mehdi On 21 November 2011 09:09, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 19/11/2011 11:04, mehdi houshmand wrote: Hi Simon, Hi Mehdi, My apologies, I did float the idea about the layout engine tests and kept to the suggestions that were given me. As such, creating tests is exactly the same and the subset of tests run are still configurable via System properties. The behaviour is the same, the only difference made is in the implementation. As for JUnit4 and Jacoco, these are primarily for developers and I'm not sure what you wish to see documented? What would we document that isn't repeating information readily available elsewhere? It doesn't matter that this is a development feature. There is a development tab on the website where you can add documentation about developer tools. Simon is right, we should add some documentation about the Jacoco code coverage script, e.g. How to run it, how to interpret the results etc. If you have questions, I'd be more than happy to answer them, but below I've included a couple informative links: Here is a good introduction to Junit4: http://www.ibm.com/developerworks/java/library/j-junit4/index.html This is a fairly good analysis of Jacoco listing pros and cons, by the people at Eclipse: http://wiki.eclipse.org/JaCoCo/Proposal There are plenty of other code-coverage tools, but I chose Jacoco for predominantly a single feature: It can be used to analyse code coverage of integration (end-to-end) tests. This would provide valuable stats for assessing the testing framework. http://www.eclemma.org/jacoco/trunk/doc/agent.html Hope that helps Thanks, Chris Mehdi On 18 November 2011 18:42, Simon Peppingspepp...@leverkruid.eu wrote: Mehdi has recommended himself to the FOP team by taking new initiatives, such as Junit4 and Jacoco. But where is the documentation? See e.g. the wiki page HowToCreateLayoutEngineTests: Does that still apply? How do I know what jacoco is and how to run it? Should I just be in the know? Please, consider adding and updating documentation of new and renewed build and test tools. Simon
Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed
This appears to be failing because Gump doesn't have Mockito in its class-path, I think it needs to be added to the Gump Metadata (http://svn.apache.org/repos/asf/gump/metadata/project/xml-fop.xml), does anyone know how I do this? Thanks Mehdi On 23 November 2011 07:50, Jeremias Maerki jerem...@apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project xml-fop-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-test : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/xml-fop/build/test-reports The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html Work Name: build_xml-fop_xml-fop-test (Type: Build) Work ended in a state of : Failed Elapsed: 27 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Dant.build.clonevm=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml gump-test [Working Directory: /srv/gump/public/workspace/xml-fop] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/test-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-fop/build/fop.jar:/srv/gump/public/workspace/xml-fop/build/fop-sandbox.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspac e/xmlgraphics-commons/build/xmlgraphics-commons-23112011.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-gvt.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-pars
Re: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed
See https://issues.apache.org/jira/browse/GUMP-167, hopefully it will be resolved in the next build. On 23 November 2011 09:41, mehdi houshmand med1...@gmail.com wrote: This appears to be failing because Gump doesn't have Mockito in its class-path, I think it needs to be added to the Gump Metadata (http://svn.apache.org/repos/asf/gump/metadata/project/xml-fop.xml), does anyone know how I do this? Thanks Mehdi On 23 November 2011 07:50, Jeremias Maerki jerem...@apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project xml-fop-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-test : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/xml-fop/build/test-reports The following work was performed: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/gump_work/build_xml-fop_xml-fop-test.html Work Name: build_xml-fop_xml-fop-test (Type: Build) Work ended in a state of : Failed Elapsed: 27 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Dant.build.clonevm=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml gump-test [Working Directory: /srv/gump/public/workspace/xml-fop] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/xml-fop/build/classes:/srv/gump/public/workspace/xml-fop/build/codegen-classes:/srv/gump/public/workspace/xml-fop/build/test-classes:/srv/gump/public/workspace/xml-fop/lib/build/asm-3.1.jar:/srv/gump/public/workspace/xml-fop/lib/build/qdox-1.12.jar:/srv/gump/public/workspace/xml-fop/build/fop.jar:/srv/gump/public/workspace/xml-fop/build/fop-sandbox.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspac e/xmlgraphics-commons/build/xmlgraphics-commons-23112011.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/batik-slideshow.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/batik-svgpp.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-anim.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-awt-util.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-bridge.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-codec.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-css.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-dom.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-ext.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-extension.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-gui-util.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-gvt.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-pars er.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-script.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-svg-dom.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-svggen.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-swing.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-transcoder.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-util.jar:/srv/gump/public/workspace/xml-batik/batik-23112011/lib/batik-xml.jar:/srv/gump/packages/apache-attic/avalon-framework-api-4.3.jar:/srv/gump/packages/apache-attic/avalon-framework-impl-4.3.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-23112011.jar:/srv/gump/public/workspace/apache-commons/io/target
Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/
This change has been reverted, please see https://issues.apache.org/bugzilla/show_bug.cgi?id=52513 On 23 January 2012 18:38, Jonathan Levinson jonathan.levin...@intersystems.com wrote: I have no vote, but I’m not happy with the change since it will break our RenderServer.jar which is a client-server we use for giving rendering tasks to FOP. In the worst case, we will have to build two versions of the jar – one for fop 1.0 and the other for people who are using trunk. This is far from ideal. A software contract is a software contract. Once it has been set, and is in the field. it should be adhered to unless there are powerful overriding reasons that compel a change. Best Regards, Jonathan Levinson Senior Software Developer Object Group InterSystems +1 617-621-0600 From: Glenn Adams [mailto:gl...@skynav.com] Sent: Monday, January 23, 2012 1:22 PM To: fop-dev@xmlgraphics.apache.org Cc: mehdi Subject: Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/org/apache/fop/render/awt/ src/java/org/apache/fop I'm disturbed that such a change has been committed without a public discussion of the merits, risks, etc., of making such a breaking change. Please revert this commit, conduct a public discussion, then, based on the results, implement the consensus. I have no idea if there is a consensus for this change without having a discussion. Regards, Glenn On Mon, Jan 23, 2012 at 9:15 AM, me...@apache.org wrote: Author: mehdi Date: Mon Jan 23 16:15:23 2012 New Revision: 1234877 URL: http://svn.apache.org/viewvc?rev=1234877view=rev Log: Moved the FOUserAgent into the constructor of the Renderers This breaks the public API but for good reasons: 1) the user-agent is essential for configuring the renderers 2) instantiation of the constructor is always followed by call to setUserAgent() (in the examples) 3) simplifies the API and reduces mutability of the Renderers
Re: Re: svn commit: r1235191 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java
Done in r1235358.
On 24 January 2012 14:47, Chris Bowditch bowditch_ch...@hotmail.com wrote:
Hi Mehdi,
On 24/01/2012 10:02, me...@apache.org wrote:
Author: mehdi
Date: Tue Jan 24 10:02:36 2012
New Revision: 1235191
URL: http://svn.apache.org/viewvc?rev=1235191view=rev
Log:
Corrected typo in error message
Well spotted. I think it's great that we now get an error instead of a
corrupt PDF in the case of license restricted Fonts, but the message
could be clearer, i.e. it does not say why the font is not embedable.
IMHO, the following would be clearer still:
String msg = The license of font + this.fontFileURI + does not allow it
to be embedded in the output file.;
Thanks,
Chris
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java?rev=1235191r1=1235190r2=1235191view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java
Tue Jan 24 10:02:36 2012
@@ -173,7 +173,7 @@ public class TTFFontLoader extends FontL
if (ttf.isEmbeddable()) {
returnFont.setEmbedFileName(this.fontFileURI);
} else {
- String msg = The font + this.fontFileURI + is not
embedabble.;
+ String msg = The font + this.fontFileURI + is not
embeddable.;
throw new RuntimeException(msg);
}
}
-
To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/
I've spent some time looking through the examples and the documentation above and I think the classes listed below are all the classes necessary for most the use-cases and thus should be considered the public API. org.apache.fop.apps.* org.apache.fop.fo.FOEventHandler org.apache.fop.fonts.FontManager org.apache.fop.events.EventListener org.apache.fop.events.Event org.apache.fop.events.model.EventSeverity org.apache.fop.render.RendererFactory org.apache.fop.render.intermediate.IFDocumentHandler org.apache.fop.render.intermediate.IFParser org.apache.fop.render.intermediate.IFUtil org.apache.fop.render.intermediate.IFSerializer org.apache.fop.render.intermediate.IFContext This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. Obviously I would also give instructions to use the IFDocumentHandler implementation. Also, while we're at it, the IFDocumentHandler method isn't described on the link above, so I'll try and put some information there as well. I plan to put this information on the website, so please feel free to discuss if you have any questions and/or wish to make amendments. Mehdi On 24 January 2012 19:36, Glenn Adams gl...@skynav.com wrote: On Tue, Jan 24, 2012 at 10:08 AM, Vincent Hennebert vhenneb...@gmail.com wrote: I would consider to be part of the public API the code that is present on the following page: http://xmlgraphics.apache.org/fop/trunk/embedding.html I agree. We should distinguish between APIs documented as being explicitly part of the embedding APIs and other public interfaces/members not documented as such. Also, it is probably good to review, at least during every release, whether the embedding API documentation is correct and complete.
Static main methods
Hi, Another proposal for public consideration: There seem to be an awful lot of static main methods around the fonts and hyphenation packages, I was wondering if anyone had any objections to moving all these methods into classes under a single package i.e. org.apache.fop.cli.utils. This would involve more than merely copy/pasting the main method itself, but also some of the ancillary methods that are only used by static main methods. Obviously, this would include updating the documentation to reflect the migration. The reason I'm making this proposition is that I'm trying to unify the URI resolution and file access within FOP, we currently use 5 URI resolvers, without including what XMLGraphics and Batik do, (FOURIResolver, FontResolver, HyphenationTreeResolver, DataURIResolver, DTDEntityResolver) which I think we can all agree is a little excessive. In so doing, I keep bumping up against these static main methods or functions that are only called by them, and it seems to me that while I'm at it, I might as well do some clean up. Anyways your collective thoughts would be appreciated on the matter, Mehdi
Re: Definition of Public API was (Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/jav
Well spotted Alexios, I will add both and double check there is adequate documentation on usage. Mehdi On 27 January 2012 20:50, Alexios Giotis alex.gio...@gmail.com wrote: I suggest to add 2 more classes to what is considered a public API. 1. org.apache.fop.render.intermediate.IFException This is obvious. Let's add it even though nobody will probably make there any backwards incompatible change. 2. org.apache.fop.render.intermediate.util.IFConcatenator It makes no sense including the IFSerializer class and leaving out the class that reads FOP IF files and creates the final output format. This is used at least in embedding.intermediate.ExampleConcat.java Alexios Giotis On Jan 27, 2012, at 1:23 PM, Chris Bowditch wrote: On 25/01/2012 14:59, mehdi houshmand wrote: Hi Mehdi, I've spent some time looking through the examples and the documentation above and I think the classes listed below are all the classes necessary for most the use-cases and thus should be considered the public API. org.apache.fop.apps.* org.apache.fop.fo.FOEventHandler org.apache.fop.fonts.FontManager org.apache.fop.events.EventListener org.apache.fop.events.Event org.apache.fop.events.model.EventSeverity org.apache.fop.render.RendererFactory org.apache.fop.render.intermediate.IFDocumentHandler org.apache.fop.render.intermediate.IFParser org.apache.fop.render.intermediate.IFUtil org.apache.fop.render.intermediate.IFSerializer org.apache.fop.render.intermediate.IFContext This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. Obviously I would also give instructions to use the IFDocumentHandler implementation. Also, while we're at it, the IFDocumentHandler method isn't described on the link above, so I'll try and put some information there as well. Thanks for preparing the list of classes that form the public API. I have chcked the code that we use to embed FOP and it's all present in the above list. A shame that its necessary to use classes from render.intermediate in order to go FO-IF-PDF. In an ideal world those classes should be in a top level intermediate package or a sub package of apps, but that won't be easy to change now! +1 to adding the above list to the website so we now have a clear definition of what is part of the API and what is not. The changes you propose to the move foUserAgent to the Renderer constructors do not affect any of the above API classes so +1 to commit those too. Thanks, Chris I plan to put this information on the website, so please feel free to discuss if you have any questions and/or wish to make amendments. Mehdi On 24 January 2012 19:36, Glenn Adamsgl...@skynav.com wrote: On Tue, Jan 24, 2012 at 10:08 AM, Vincent Hennebertvhenneb...@gmail.com wrote: I would consider to be part of the public API the code that is present on the following page: http://xmlgraphics.apache.org/fop/trunk/embedding.html I agree. We should distinguish between APIs documented as being explicitly part of the embedding APIs and other public interfaces/members not documented as such. Also, it is probably good to review, at least during every release, whether the embedding API documentation is correct and complete.
Re: Static main methods
On 27 January 2012 20:17, J.Pietschmann j3322...@yahoo.de wrote: Am 27.01.2012 16:35, schrieb mehdi houshmand: There seem to be an awful lot of static main methods around the fonts and hyphenation packages, I was wondering if anyone had any objections to moving all these methods into classes under a single package i.e. AFAIR all of these are there to facilitate development and testing, the font metrics and the hyphenation class generator being the only exceptions. They are not meant for the average user. Most if not all could probably be deleted, or a least moved into the test tree. Though I agree with you, and would like to do that, I'm a little apprehensive about removing functionality, there's always a use case you're not taking into account. Moving them to a place we can isolate (*cough* ignore) is sufficient for now. snip/ Unfortunately, there are at least two different APIs involved, and there are still reasons users should be able to set different resolvers for different purposes. Using an underlying unified API makes sense, however I remember unifying DTDEntityResolver and the other Resolvers run into difficulties (maybe related to XML catalogs). J.Pietschmann Ignoring the API differences, the only reason I can think that people would need multiple resolvers is to create a disparity between the fop.xconf and the input. This is only a problem with relative URIs - where to resolve the relative base directory from. URIs in the fop.xconf are resolved relative to the conf file, and those in the input are relative to the input file (be it FO or IF). This behaviour will have to be maintained. Other than that, there doesn't seem to be any reason why multiple resolvers are necessary. Any specialized handling of URIs can be controlled by embedding details in the URI itself, for example, if you want fonts to be pulled from some remotely, just use font: as the scheme, and set your URI resolver to handle the font scheme appropriately. The only reason this scheme method can't be used to create a disparity between the input-base and conf-base is because we can't define a scheme for relative URIs, it is prohibited by the URI spec. If I'm missing a use-case or mistaken in some way, please feel free to correct my assumptions, getting URI resolution wrong is a serious mistake.
Re: svn commit: r1234877 - in /xmlgraphics/fop/trunk: examples/embedding/java/embedding/ examples/embedding/java/embedding/atxml/ src/java/org/apache/fop/cli/ src/java/org/apache/fop/render/ src/java/
Yes, I believe you're correct, but this I think can be considered to be a quite advanced use-case and as such not relevant to the public API. Since there are still unknowns, I'll leave it for now, no doubt this will be discussed again in the future. On 28 January 2012 11:19, J.Pietschmann j3322...@yahoo.de wrote: Am 25.01.2012 15:59, schrieb mehdi houshmand: This would mean deprecating o.a.f.apps.FOUserAgent.setRendererOverride(...) since (if I'm not mistaken) this is legacy code to bind a MIME type to IF output. AFAIR it was meant as a hook for users providing their own renderer, overriding built-in renderers for the same MIME type. E.g. some hacked-up AFP-renderer or something. I wish Jeremias would come forward and provide some more background. J.Pietschmann
Re: checkstyle errors, deprecation
This has been amended in r1237610. However just to note, this strictly speaking shouldn't be a checkstyle error, FOP is Java5 compliant not Java6, and as such that method isn't deprecated. On 27 January 2012 17:44, Glenn Adams gl...@skynav.com wrote: I notice 4 checkstyle errors have creeped into recent trunk commits. Also, there is a deprecated usage in one of the junit tests (run junit-compile target) that has been around for a while that should be fixed: % ant junit-compile ... [javac] /users/glenn/Work/fop/test/java/org/apache/fop/fonts/truetype/TTFFontLoaderTestCase.java:42: warning: [deprecation] toURL() in java.io.File has been deprecated [javac] String absoluteFilePath = file.toURL().toExternalForm(); Maybe a committer could fix these.
URI Resolution
Hi, As I've said previously, I've been looking at unifying URI resolution, I've looked at a lot of the code regarding this and from what I can see FOP uses file access for the following types of files: 1) Input/Output files - by that I mean FO and output, both of which are many-to-many 2) Resources - fonts, images, hyphenation-patterns, colour profiles etc 3) AFP resource file - arguably could be an Output type, but not handled in the same way 4) Scratch files - used for caching and optimize-resources etc I think a lot of the URI differentiation can be done within the URI itself, so we can use just an interface with two methods: InputStream getInputStream(URI); OutputStream getOutputStream(URI); This interface will be bound to the FOUserAgent and a setter on the user agent will allow clients to define their own implementation. I think we can avoid having Source getSource(URI) in the API by using converting them into a javax.xml.transform.Source when necessary with new StreamSource(InputStream) (same for OutputStream-StreamResult). The only issue here is that Source objects also hold their URI, so if the source object is created one place, and the URI is read in another, that could be problematic. They're passed around a lot, so it's not so easy to chase them all the way through the rabbit hole. There are, however, a few more unknowns most relating to images, because I haven't seen how these are used in xgc-commons or batik. But no doubt we're going to have to make API changes to them anyway so we might as well cross that bridge when we come to it. I think we do this incrementally though, since it's going to touch so many areas of code, I think the best idea is to do this in steps. I will create a branch for Apache so each changes are made publicly available, so do keep an eye on it, since the changes will have quite far reaching effects. In terms of the nuts and bolts, I think the biggest difficulties here are to do with clean up. There is a disappointing amount of very similar but not quite the same code which is going to be tricksy. In terms of worries about regressions or the like, I will do my best to minimize any impact, however, there are quite a few different URI resolution methodologies. If say you're using a custom FontResolver and a custom FOUriResolver, then there will be an impact. So I think the best course of action is to start with the fonts packages, since it's probably the area of code I'm most comfortable with, replacing the various URI resolution methods with a single one. Thoughts? Mehdi
Re: junit-{basic,fotree} regression in trunk
Hi Glenn, I fixed this issue in r1243549, this was a mistake made during the migration to Junit4 (i.e. my fault). The reason junit-all doesn't invoke these tests is because it runs a regex (**/*TestCase.java), which (rather ironically in this case) catches more of the tests than the TestSuites did. The problem is that when tests are added, people have forgotten to add tests to the appropriate TestSuite, an easy mistake, and not easy to spot. See the links below: See (https://issues.apache.org/bugzilla/show_bug.cgi?id=52136) and (http://markmail.org/message/b5rtyyvxgbud32fh?q=list:org%2Eapache%2Exmlgraphics%2Efop-dev+junit4#query:list%3Aorg.apache.xmlgraphics.fop-dev%20junit4+page:1+mid:mugutpvibrurhz4t+state:results) On 11 February 2012 19:42, Glenn Adams gl...@skynav.com wrote: i noticed today that junit-basic and junit-fotree targets both fail in trunk; i'm not sure when this regression occurred, but it would be nice if all junit targets pass in trunk; it also makes me wonder if junit-all is exercising all the tests from these two targets; junit-basic ... Testcase: testJpegImageConfig took 0.059 sec Testcase: initializationError took 0.002 sec Caused an ERROR No runnable methods java.lang.Exception: No runnable methods at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) Testcase: testJPEGImageLevel3 took 0.111 sec ... junit-fotree ... Testcase: initializationError took 0.032 sec Caused an ERROR No runnable methods java.lang.Exception: No runnable methods at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) Testcase: testGetNextSimplePageMasterException took 0.42 sec ...
Re: svn commit: r1243963 - in /xmlgraphics/fop/trunk: build.xml test/java/org/apache/fop/fo/pagination/RepeatablePageMasterAlternativesTestCase.java test/layoutengine/disabled-testcases.xml
Sorry, I should have said, this was an issue spotted by Glenn Adams.
Thanks for flagging it up Glenn!
Mehdi
On 14 February 2012 14:48, me...@apache.org wrote:
Author: mehdi
Date: Tue Feb 14 14:48:00 2012
New Revision: 1243963
URL: http://svn.apache.org/viewvc?rev=1243963view=rev
Log:
Enabled assertions in junit tasks (analagous to JVM arg -ea)
- Disabled a layout test that fails an assertion
- Added an expression to a mocked class to pass assertion
Modified:
xmlgraphics/fop/trunk/build.xml
xmlgraphics/fop/trunk/test/java/org/apache/fop/fo/pagination/RepeatablePageMasterAlternativesTestCase.java
xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.xml
Modified: xmlgraphics/fop/trunk/build.xml
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/build.xml?rev=1243963r1=1243962r2=1243963view=diff
==
--- xmlgraphics/fop/trunk/build.xml (original)
+++ xmlgraphics/fop/trunk/build.xml Tue Feb 14 14:48:00 2012
@@ -787,6 +787,9 @@ list of possible build targets.
classpath
path refid=@{classpath}/
/classpath
+ assertions
+ enable/
+ /assertions
test name=@{testsuite} todir=${junit.reports.dir}
outfile=@{outfile}/
/junit
/sequential
@@ -801,6 +804,9 @@ list of possible build targets.
classpath
path refid=standard-junit-classpath/
/classpath
+ assertions
+ enable/
+ /assertions
batchtest todir=${junit.reports.dir}
fileset dir=${build.unit.tests.dir} includes=**/*TestCase.class/
/batchtest
Modified:
xmlgraphics/fop/trunk/test/java/org/apache/fop/fo/pagination/RepeatablePageMasterAlternativesTestCase.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/test/java/org/apache/fop/fo/pagination/RepeatablePageMasterAlternativesTestCase.java?rev=1243963r1=1243962r2=1243963view=diff
==
---
xmlgraphics/fop/trunk/test/java/org/apache/fop/fo/pagination/RepeatablePageMasterAlternativesTestCase.java
(original)
+++
xmlgraphics/fop/trunk/test/java/org/apache/fop/fo/pagination/RepeatablePageMasterAlternativesTestCase.java
Tue Feb 14 14:48:00 2012
@@ -158,6 +158,7 @@ implements Constants {
when(pList.get(anyInt())).thenReturn(maximumRepeats);
PageSequenceMaster parent = mock(PageSequenceMaster.class);
+ when(parent.getName()).thenReturn(fo:page-sequence-master);
RepeatablePageMasterAlternatives sut = new
RepeatablePageMasterAlternatives(parent);
Modified: xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.xml
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.xml?rev=1243963r1=1243962r2=1243963view=diff
==
--- xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.xml (original)
+++ xmlgraphics/fop/trunk/test/layoutengine/disabled-testcases.xml Tue Feb 14
14:48:00 2012
@@ -209,4 +209,9 @@
descriptionThe block should cause overflow in the
last column on the page, rather than be broken./description
/testcase
+ testcase
+ nameBlock Container Reference Orientation Bug/name
+ fileblock-container_reference-orientation_bug36391.xml/file
+ descriptionAn assert is failing/description
+ /testcase
/disabled-testcases
-
To unsubscribe, e-mail: fop-commits-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-h...@xmlgraphics.apache.org
Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
Hi, I was running o.a.f.intermediate.IFParserTestCase in Eclipse, and found it extremely frustrating that the schema (xml.xsd) had to be in the same folder as the test class?!?! Why? It means, if I want to run said test with the Eclipse Junit Runner, I have to copy it into the proper directory, manually. In related news, when I run ant junit, it chokes every time for a minute on checking the cached xsd file. I mean, it's obviously not the end of the world, but it is annoying and I'm questioning if it's necessary? Gump fails, periodically because of this same issue, which is annoying at best, and quite dangerous since false positives on a CI server... I don't need to preach to the choir here. Can we not assume that the normal W3C software license [1] applies here? If not, their document license [2]? If so, as per the Apache legal recommendations [3], we're thumbs up for distributing this file (with the notice). If either of those assumptions aren't valid, I'd be happy to ask the Apache legal team, they can at least resolve the ambiguity about the license. Just wanted to know your thoughts? This has been bugging me for a while... Mehdi [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.html [3] http://www.apache.org/legal/resolved.html#category-a On 10 November 2011 12:20, Vincent Hennebert vhenneb...@gmail.com wrote: On 10/11/11 09:31, Simon Pepping wrote: It is not a good idea to fetch xml.xsd from W3C each time. Put it in the sources and if necessary use a catalog. xml.xsd is already available at src/documentation/intermediate-format-ng/xml.xsd. Hmmm. Apparently Gump deletes the workspace directory before every build, which pretty much kills the benefits of the caching process that I had put in place in rev. 1186858. FWIW, I did have in mind to use a catalog, but AFAICT the catalog-based resolver available from XML Commons Resolver is not compatible with what is used by XML Schema (org.w3c.dom.ls.LSResourceResolver vs org.xml.sax.EntityResolver or javax.xml.transform.URIResolver). Also, using a catalog seemed a bit overkill for this. Storing xml.xsd locally is an option, but: • we lose the link to http://www.w3.org/2001/xml.xsd (although I suppose we can say that it’s obvious from looking at the content of the file) • if the original schema ever gets updated, we get out of sync (although I suppose that’s unlikely to happen) • most of all, are we allowed to redistribute this file? I couldn’t find any license information with it. For those reasons I chose to download it into some cache directory. I could remove this caching mechanism and point to src/documentation/intermediate-format-ng/xml.xsd instead, if bullet 3 above is not an issue. Thoughts? Thanks, Vincent Simon On Thu, Nov 10, 2011 at 08:27:53AM +, Jeremias Maerki wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project xml-fop-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 61 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-test : XSL-FO (Formatting Objects) processor Full details are available at: http://vmgump.apache.org/gump/public/xml-fop/xml-fop-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/xml-fop/build/test-reports
Re: URI Resolution
Hi Jeremias, I'll address your concerns inline: snip/ First, I would like to suggest you start with listing relevant code portions on the wiki before anything else. Where is what? And what's the problem with each case? Right now there are only a few vague pointers and an underlying unhappiness with the various approaches. My apologies for any lack of clarity on my part, the issues around URI resolution are in no way due to any unhappiness on my part. Infact, rather frustratingly, great effort has been made to have fallback mechanisms to allow ambiguity from the user (which I'm sure we all know happens all too often). However, as far as I can tell, URI resolution is a single problem, and as such, should have a single solution. Now, I do appreciate there are nuances involved, but allowing for them (which I'll discuss later) there should be a single URI resolution mechanism. The problem I'm trying to tackle here is how do we sandbox FOPs file access? With the current implementation, that isn't possible. There's too much contingency i.e. if this resolved URI doesn't exist, check this one. As I've said, in the cloud, we have to be very strict, we cannot allow one user to gain access (intentionally or otherwise) to another users data. snip/ I think it can be useful to think about simplifying the use of URIResolver to new interface for resource resolution where only InputStreams are required. IMO, it should then still be possible to use a URIResolver to resolve those URIs. An adapter for URIResolvers should be possible to write. I spent quite some time deliberating on which approach would be best, returning an InputStream or a Source object. The problem is, the only time FOP actually reads XML is when parsing SVG. Even reading the FO is done by the JAXP transformer. So I do appreciate the JAXP system is tried and tested, but using that API isn't the best approach, IMO. The reason being that everytime we want to convert a Source object to an InputStream, we need to re-write the code that does so, which is non-trivial since that is where the URI is actually resolved. We could cast Source to StreamSource, but that returns an InputStream anyway. snip/ I get the impression that you're suggesting that only a single base URI (on the FopFactory?) is required. In the past, we've had to add multiple base URIs precisely because there isn't a single base URI. Some URIs need to be resolved relative to the input FO document (base URI on FOUserAgent.base). Or they need to be resolved relative to the XSLT stylesheet in use (images may or may not be stored next to the XSLT stylesheets). Fonts (FontManager.fontBase) and hyphenation patterns (FopFactory.hyphenBase) may be at a different location respectively. Or they could simply be relative to the main configuration file (FopFactory.base). Granted, that adds complexity but also flexibility for those who need it. So here's the problem: whichever client that is calling FOP, gives it a URI resolver. This resolver, all it does, is convert a URI to an InputStream, it shouldn't need to hold any state (i.e. base URI). Now, having all these base URIs is going to get pretty confusing no? I think all that's needed is font-base and base (defined in the fop.xconf). Without getting too much into the nuts and bolts, this is where the wrapper comes in. The wrapper holds the state (defined by the user when FopFactory is instantiated and/or in the fop.xconf), and it can resolve against the base, giving the user defined resolver an absolute URI to read from. This would allow users to define their own URIs and a single resolution mechanism. Not only does this give the security of sandboxing, it also allows for the full flexibility of URIs to be exploited. The user can define their own schemes, queries etc and the resource being read doesn't even need to be on the file system. It could be in a database; a remote resource; whatever as long as it can be resolved and converted to an InputStream. Looking at that, the signature InputStream getInputStream(URI) may be insufficient. Like in URIResolver, you may need to extend that to InputStream getInputStream(URI resource, URI base), so you can get the URI resolved against the applicable base URI of the context you're working in (fonts, hyph patterns, config files etc.). OTOH, we have some special resolution interfaces (like FontResolver) which don't have a base URI because it is implicit and handled by the caller. The various specialized resolver interfaces help decouple the various packages from neighbouring ones to reduce dependencies. I think I've addressed most of these concerns above, but I believe the user already defines a base with fop-base or base in the fop.xconf. So these should be used to resolve relative URIs. In terms of decoupling, I don't think I could agree more. The fonts packages especially are in dire need of some TLC, and extracting them to their own module is what I've been pushing for.
Re: Implementing PDF Object Streams
Hi Craig, Just out of curiosity, what issues are you having with the pdf-image-plugin? I spent quite a lot of time with it and submitted a patch to Jeremias (not sure if he's committed it). Maybe we could help you there? We've also got some commits lying around that we're not happy with per-se because they sacrifice rendered fidelity for file size that may help you. Let us know what you've done and what you're trying to do in a new thread and I'll let you know if we can help. Mehdi On 28 February 2012 00:39, Craig Ringer ring...@ringerc.id.au wrote: On 27/02/2012 8:08 PM, Vincent Hennebert wrote: We would like to implement PDF Object Streams as defined in the PDF 1.5 Reference. In short, the structure tree would be stored inside a stream to allow for compression in the same way as the page content. What's the status of object stream support in PDFBox? Is it possible the feature is bettern implemented by adopting a PDFBox based backend? There's been long term planning talk of moving over to PDFBox as the underlying PDF support library. It'd massively simplify work with PDF-in-PDF embedding, reduce maintenance work, etc. Is it worth doing major enhancement work on fop's pdf library if it may go away in future? I'm struggling with getting fop and pdfbox to play well together at the moment as I work on enhancing fop-pdf-image to merge duplicate font subsets. The use of two different pdf libraries makes fop-pdf-image much more complex and makes working with fonts a lot harder. I'm sure it's not the only area where a pdfbox-based backend might be good. -- Craig Ringer
Re: Google Summer of Code
Hi Glenn, The GSoC doesn't relate directly to the ASF or FOP directly, however, putting a few FOP projects as proposals would be a good way to get some new interest into the project. I think it would be good for us as we benefit from any work done, and it helps whomever does the work learn the various skills that we as a community can impart upon them. I've included a link to the GSoC below, but if you do some research, there's plenty of information out there. http://code.google.com/soc/ Mehdi On 1 March 2012 16:13, Glenn Adams gl...@skynav.com wrote: could you provide a link to the Google Summer of Code Project? how does it relate to ASF and FOP activities? On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand med1...@gmail.com wrote: Hi, We're thinking of submitting a proposal or two to the Google Summer of Code project and wanted to get some input from the community on ideas. Once we've got a few proposals I'll create a wiki page and put all the ideas on there, but for now I just wanted to gauge interest. In terms of mentoring, I'm happy to be a mentor and I've registered as one and if any other committers fancy the job, do register, the more the merrier. The deadline is 9th March, so that doesn't give us long to bounce around ideas, but here are a few I was thinking: - There have been recent discussions between Jeremias, myself and others about extracting the Fonts packages into their own library. I think this would be a great idea for a project because essentially it only involves a few, well defined specifications (TTF, Type1 etc) and doesn't expose the person to too much complexity. The way I'd suggest this to be done, is by re-writing rather than porting, that way it gives the person much more flexibility and also the current code would give them good tips and tricks on how to deal with parsing fonts. - TTF in AFP. I know we still have the TrueTypeInPostScript branch flying around, and however much I'd like to fob that onto someone else, I don't think it's fair to do so. I have no idea how long this project would take, but I think FOP could really benefit from it. Currently we're forcing users to use AFP fonts for AFP documents, a lot of which are archaic and use EBCDIC, for those of you who haven't been exposed to EBCDIC, count yourself lucky. There may be something to do with PCL?? I'm not at all familiar with the format, but I do remember discussions about upgrading to a newer PCL standard? I'd be happy to acquaint myself with the format if there's interest in the idea. Hopefully we can get a proposal together in time. Mehdi
Re: Google Summer of Code
Because of the overwhelming popularity of this idea, I've created a link on the Wiki (http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2012) for the GSoC proposals. On a serious note, this is literally work for free. Google pays the bills and I'm happy to mentor any applicants and do the admin, all you have to do is provide ideas for projects. If you have a wish list or a list of TODOs that you think a newbie could do for a summer project (I do appreciate that's quite a big caveat), now's your opportunity. Mehdi On 1 March 2012 16:26, mehdi houshmand med1...@gmail.com wrote: Hi Glenn, The GSoC doesn't relate directly to the ASF or FOP directly, however, putting a few FOP projects as proposals would be a good way to get some new interest into the project. I think it would be good for us as we benefit from any work done, and it helps whomever does the work learn the various skills that we as a community can impart upon them. I've included a link to the GSoC below, but if you do some research, there's plenty of information out there. http://code.google.com/soc/ Mehdi On 1 March 2012 16:13, Glenn Adams gl...@skynav.com wrote: could you provide a link to the Google Summer of Code Project? how does it relate to ASF and FOP activities? On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand med1...@gmail.com wrote: Hi, We're thinking of submitting a proposal or two to the Google Summer of Code project and wanted to get some input from the community on ideas. Once we've got a few proposals I'll create a wiki page and put all the ideas on there, but for now I just wanted to gauge interest. In terms of mentoring, I'm happy to be a mentor and I've registered as one and if any other committers fancy the job, do register, the more the merrier. The deadline is 9th March, so that doesn't give us long to bounce around ideas, but here are a few I was thinking: - There have been recent discussions between Jeremias, myself and others about extracting the Fonts packages into their own library. I think this would be a great idea for a project because essentially it only involves a few, well defined specifications (TTF, Type1 etc) and doesn't expose the person to too much complexity. The way I'd suggest this to be done, is by re-writing rather than porting, that way it gives the person much more flexibility and also the current code would give them good tips and tricks on how to deal with parsing fonts. - TTF in AFP. I know we still have the TrueTypeInPostScript branch flying around, and however much I'd like to fob that onto someone else, I don't think it's fair to do so. I have no idea how long this project would take, but I think FOP could really benefit from it. Currently we're forcing users to use AFP fonts for AFP documents, a lot of which are archaic and use EBCDIC, for those of you who haven't been exposed to EBCDIC, count yourself lucky. There may be something to do with PCL?? I'm not at all familiar with the format, but I do remember discussions about upgrading to a newer PCL standard? I'd be happy to acquaint myself with the format if there's interest in the idea. Hopefully we can get a proposal together in time. Mehdi
Re: Google Summer of Code
Haha, if only it were that simple... The projects have to be interesting and fulfilling and at least bordering on fun. They also have to be an opportunity to learn and encourage opensource development. There's little fun to be had fixing bugs hidden in the depths of FOPs fairly difficult to delve-in code base, also - probably more importantly - I can't imagine it would serve as encouragement. Mehdi On 5 March 2012 14:36, Glenn Adams gl...@skynav.com wrote: I would suggest whittling down the fop bug list, starting from the beginning. On Mon, Mar 5, 2012 at 6:35 AM, mehdi houshmand med1...@gmail.com wrote: Because of the overwhelming popularity of this idea, I've created a link on the Wiki (http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2012) for the GSoC proposals. On a serious note, this is literally work for free. Google pays the bills and I'm happy to mentor any applicants and do the admin, all you have to do is provide ideas for projects. If you have a wish list or a list of TODOs that you think a newbie could do for a summer project (I do appreciate that's quite a big caveat), now's your opportunity. Mehdi On 1 March 2012 16:26, mehdi houshmand med1...@gmail.com wrote: Hi Glenn, The GSoC doesn't relate directly to the ASF or FOP directly, however, putting a few FOP projects as proposals would be a good way to get some new interest into the project. I think it would be good for us as we benefit from any work done, and it helps whomever does the work learn the various skills that we as a community can impart upon them. I've included a link to the GSoC below, but if you do some research, there's plenty of information out there. http://code.google.com/soc/ Mehdi On 1 March 2012 16:13, Glenn Adams gl...@skynav.com wrote: could you provide a link to the Google Summer of Code Project? how does it relate to ASF and FOP activities? On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand med1...@gmail.com wrote: Hi, We're thinking of submitting a proposal or two to the Google Summer of Code project and wanted to get some input from the community on ideas. Once we've got a few proposals I'll create a wiki page and put all the ideas on there, but for now I just wanted to gauge interest. In terms of mentoring, I'm happy to be a mentor and I've registered as one and if any other committers fancy the job, do register, the more the merrier. The deadline is 9th March, so that doesn't give us long to bounce around ideas, but here are a few I was thinking: - There have been recent discussions between Jeremias, myself and others about extracting the Fonts packages into their own library. I think this would be a great idea for a project because essentially it only involves a few, well defined specifications (TTF, Type1 etc) and doesn't expose the person to too much complexity. The way I'd suggest this to be done, is by re-writing rather than porting, that way it gives the person much more flexibility and also the current code would give them good tips and tricks on how to deal with parsing fonts. - TTF in AFP. I know we still have the TrueTypeInPostScript branch flying around, and however much I'd like to fob that onto someone else, I don't think it's fair to do so. I have no idea how long this project would take, but I think FOP could really benefit from it. Currently we're forcing users to use AFP fonts for AFP documents, a lot of which are archaic and use EBCDIC, for those of you who haven't been exposed to EBCDIC, count yourself lucky. There may be something to do with PCL?? I'm not at all familiar with the format, but I do remember discussions about upgrading to a newer PCL standard? I'd be happy to acquaint myself with the format if there's interest in the idea. Hopefully we can get a proposal together in time. Mehdi
Re: Google Summer of Code
Hi Alex/Glenn, Yeah that's a fair point, I think this may be a textbook case of Freudian projection, so my apologies if those weren't your intentions Glenn. The problem is, I don't have a great deal of experience in the Layout Engine and I really have no grounds to put a proposal together. I've put forward the projects that I know about and think are interesting. If you want to put a project proposal forward please do, if no one else steps forward as a mentor and an applicant takes an interest, I'll make the effort to learn the code. Mehdi On 5 March 2012 15:48, Alexios Giotis alex.gio...@gmail.com wrote: I don't think that Glenn's idea is that bad. FOP's open bugzilla issues are not only bugs, they also show what are the areas that FOP needs to be improved. If we start from the beginning, then | 1063|New|Nor|2001-03-21|fop does not handle large fo files is a real, very interesting issue and the solution is not to increase the Java heap size. There are workarounds such as caching objects but a good solution might be deeper in FOP's layout engine. What about checking or implementing Donald Knuth's first-fit or best-fit algorithms ? In theory, it would allow to free FO tree and layout manager objects after the end of every page. There was a recent discussion about this, see http://apache.markmail.org/message/3ejv4opwcceipfpl?q=list:org%2Eapache%2Exmlgraphics%2Efop-users+total+best+fit Of course there will be drawbacks, FOP is complex (more complex than it should be in my opinion, cleanup / modularization would help) and this is not a simple task. Alex Giotis On Mar 5, 2012, at 4:49 PM, mehdi houshmand wrote: Haha, if only it were that simple... The projects have to be interesting and fulfilling and at least bordering on fun. They also have to be an opportunity to learn and encourage opensource development. There's little fun to be had fixing bugs hidden in the depths of FOPs fairly difficult to delve-in code base, also - probably more importantly - I can't imagine it would serve as encouragement. Mehdi On 5 March 2012 14:36, Glenn Adams gl...@skynav.com wrote: I would suggest whittling down the fop bug list, starting from the beginning. On Mon, Mar 5, 2012 at 6:35 AM, mehdi houshmand med1...@gmail.com wrote: Because of the overwhelming popularity of this idea, I've created a link on the Wiki (http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2012) for the GSoC proposals. On a serious note, this is literally work for free. Google pays the bills and I'm happy to mentor any applicants and do the admin, all you have to do is provide ideas for projects. If you have a wish list or a list of TODOs that you think a newbie could do for a summer project (I do appreciate that's quite a big caveat), now's your opportunity. Mehdi On 1 March 2012 16:26, mehdi houshmand med1...@gmail.com wrote: Hi Glenn, The GSoC doesn't relate directly to the ASF or FOP directly, however, putting a few FOP projects as proposals would be a good way to get some new interest into the project. I think it would be good for us as we benefit from any work done, and it helps whomever does the work learn the various skills that we as a community can impart upon them. I've included a link to the GSoC below, but if you do some research, there's plenty of information out there. http://code.google.com/soc/ Mehdi On 1 March 2012 16:13, Glenn Adams gl...@skynav.com wrote: could you provide a link to the Google Summer of Code Project? how does it relate to ASF and FOP activities? On Thu, Mar 1, 2012 at 3:50 AM, mehdi houshmand med1...@gmail.com wrote: Hi, We're thinking of submitting a proposal or two to the Google Summer of Code project and wanted to get some input from the community on ideas. Once we've got a few proposals I'll create a wiki page and put all the ideas on there, but for now I just wanted to gauge interest. In terms of mentoring, I'm happy to be a mentor and I've registered as one and if any other committers fancy the job, do register, the more the merrier. The deadline is 9th March, so that doesn't give us long to bounce around ideas, but here are a few I was thinking: - There have been recent discussions between Jeremias, myself and others about extracting the Fonts packages into their own library. I think this would be a great idea for a project because essentially it only involves a few, well defined specifications (TTF, Type1 etc) and doesn't expose the person to too much complexity. The way I'd suggest this to be done, is by re-writing rather than porting, that way it gives the person much more flexibility and also the current code would give them good tips and tricks on how to deal with parsing fonts. - TTF in AFP. I know we still have the TrueTypeInPostScript branch flying around, and however much I'd like to fob that onto someone else, I don't think it's fair to do so. I have no idea how long
Fwd: Google Summer of Code
I fat-fingered the reply button instead of reply-to-all... *face-palm* -- Forwarded message -- From: mehdi houshmand med1...@gmail.com Date: 6 March 2012 09:33 Subject: Re: Google Summer of Code To: Craig Ringer ring...@ringerc.id.au On 6 March 2012 00:16, Craig Ringer ring...@ringerc.id.au wrote: On 03/05/2012 09:35 PM, mehdi houshmand wrote: Because of the overwhelming popularity of this idea, I've created a link on the Wiki (http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2012) for the GSoC proposals. Things that come to mind for me: - PDFBox backend (probably ideal for GSoC, nice and self contained, great for someone who knows PDFBox and wants to learn fop's codebase); - CID fonts in PostScript (good for someone who knows PS and fonts, not necessarily XSL-FO so much); There is already a big body of work that does this, check the TrueTypeInPostScript branch as well as the patch https://issues.apache.org/bugzilla/show_bug.cgi?id=50483. This stuff needs to be merged into trunk and we do have that on our agenda, but... I don't make the rules. - Using automatic +- kerning, +- tracking *and* +- horizontal type scaling adjustment to better auto-fit text, involving support for font-stretch property. This touches on layout so it may not be practical for a 1st fop project, but may not be too bad since fop already adjusts tracking when justifying text. The key interest points would be *negative* tracking, kerning and (if nothing else works) glyph-scaling for tighter type-fitting where it's not desirable to break to a new line due to widow/orphan policy or because it'd create large holes. This is particularly important when long unbreakable words must fit a fixed width space. This sounds pretty interesting!! Could you put this and maybe a little more information in a proposal similar to https://issues.apache.org/jira/browse/COMDEV-66 or https://issues.apache.org/jira/browse/COMDEV-67 and I'll create a JIRA issue. - PDF/X-1a with CMYK; I have no idea what is involved here, sounds like a lot of time in the spec and battling FOP, but as I said, those are baseless assumptions. Is that an interesting project? - Anything in the proposed XSL-FO 2.0 feature list (though most of it won't be realistic for GSoC projects); - Merge fop-pdf-image and implement smart merging of font, profile, and image resources. I'm working on this one at the moment, but slowly and only amid other projects. I really don't think that's a suitable project, I responded to your post so maybe we could take this conversation else where, but this really isn't FOPs responsibilty, or for that matter the pdf-image-plugin. If anything, I'd argue that's a PDFBox project, Adobe Acrobat Pro does this kind of thing (badly may I add) as a post-process action and I think that's the correct way to do it. The other thing to say is that a new comer may not appreciate the importance of fidelity when fonts are concerned. Basically it's too difficult for a student given a few months and no previous experience. -- Craig Ringer
Fwd: Google Summer of Code
-- Forwarded message -- From: mehdi houshmand med1...@gmail.com Date: 6 March 2012 10:12 Subject: Fwd: Google Summer of Code To: fop-dev@xmlgraphics.apache.org I fat-fingered the reply button instead of reply-to-all... *face-palm* -- Forwarded message -- From: mehdi houshmand med1...@gmail.com Date: 6 March 2012 09:33 Subject: Re: Google Summer of Code To: Craig Ringer ring...@ringerc.id.au On 6 March 2012 00:16, Craig Ringer ring...@ringerc.id.au wrote: On 03/05/2012 09:35 PM, mehdi houshmand wrote: Because of the overwhelming popularity of this idea, I've created a link on the Wiki (http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2012) for the GSoC proposals. Things that come to mind for me: - PDFBox backend (probably ideal for GSoC, nice and self contained, great for someone who knows PDFBox and wants to learn fop's codebase); - CID fonts in PostScript (good for someone who knows PS and fonts, not necessarily XSL-FO so much); There is already a big body of work that does this, check the TrueTypeInPostScript branch as well as the patch https://issues.apache.org/bugzilla/show_bug.cgi?id=50483. This stuff needs to be merged into trunk and we do have that on our agenda, but... I don't make the rules. - Using automatic +- kerning, +- tracking *and* +- horizontal type scaling adjustment to better auto-fit text, involving support for font-stretch property. This touches on layout so it may not be practical for a 1st fop project, but may not be too bad since fop already adjusts tracking when justifying text. The key interest points would be *negative* tracking, kerning and (if nothing else works) glyph-scaling for tighter type-fitting where it's not desirable to break to a new line due to widow/orphan policy or because it'd create large holes. This is particularly important when long unbreakable words must fit a fixed width space. This sounds pretty interesting!! Could you put this and maybe a little more information in a proposal similar to https://issues.apache.org/jira/browse/COMDEV-66 or https://issues.apache.org/jira/browse/COMDEV-67 and I'll create a JIRA issue. - PDF/X-1a with CMYK; I have no idea what is involved here, sounds like a lot of time in the spec and battling FOP, but as I said, those are baseless assumptions. Is that an interesting project? - Anything in the proposed XSL-FO 2.0 feature list (though most of it won't be realistic for GSoC projects); - Merge fop-pdf-image and implement smart merging of font, profile, and image resources. I'm working on this one at the moment, but slowly and only amid other projects. I really don't think that's a suitable project, I responded to your post so maybe we could take this conversation else where, but this really isn't FOPs responsibilty, or for that matter the pdf-image-plugin. If anything, I'd argue that's a PDFBox project, Adobe Acrobat Pro does this kind of thing (badly may I add) as a post-process action and I think that's the correct way to do it. The other thing to say is that a new comer may not appreciate the importance of fidelity when fonts are concerned. Basically it's too difficult for a student given a few months and no previous experience. -- Craig Ringer
Fwd: fop-pdf-image and fonts; as requested
Seems I didn't forward this one to fop-dev either... My apologies. -- Forwarded message -- From: mehdi houshmand med1...@gmail.com Date: 29 February 2012 09:41 Subject: Re: fop-pdf-image and fonts; as requested To: Craig Ringer ring...@ringerc.id.au Hi Craig, We had this exact same problem the last time you brought this issue to light and our approach was slightly different. Let me first ask you the question, are you 100% that fonts are the issue here? When the pdf-image-plugin is used, ALL pdf-images are imported and wholesale creating a new XObject Form for each page. Now, this works perfectly fine for smaller documents, however, it can blow the memory stack on RIPs for larger docs. The reason being XObjects are treated as global resources of the PDF, as such, it is possible to create the XObject and use it multiple times. However, this means that each XObject and its resources, are being stored in memory on the RIP. This is different to how a RIP can handle a /Page object. When printing/rendering a /Page object, the RIP only needs the page's content stream and any resources it references in memory. Once the page is rendered, the memory can be cleared. When PDFBox merges docs, it doesn't use the XObject Form, it does so by appending /Page objects. This is the solution we came to, just adding a PDFBox merger to the pipeline. So with that in mind, what exactly are you trying to do? Why are you using FOP to merge PDFs? Do you need FOP to do this work? Have you tried merging PDFs with PDFBox and seeing how that affects the RIP? I've probably got more questions than answers there, but hopefully we can get to a solution. Mehdi On 29 February 2012 04:09, Craig Ringer ring...@ringerc.id.au wrote: Hi As requsted by Mehdi Houshmand I'm elaborating on the issue we've been running into with fop-pdf-image. I've asked about aspects of it on the list before, but now have a better understanding of what's going on. Where input pdfs being used as form XObjects contain embedded subset fonts, I'm seeing many copies of those fonts being embedded in the output document. This creates huge output files with lots of duplicate font data, and in a few cases has even crashed the RIP used by my work's offset press printer. I think they use a Firey, but struggle to get any more info than that out of them. The issue is that fop-pdf-image copies PDFs into fop output PDFs by copying the content stream and resources dictionary verbatim from the page being extracted from the input PDF, translating it from PDFBox into fop PDF structures in the process. This is extremely reliable, ensuring that fop-pdf-image form XObjects don't conflict with / interfere with the embedding page or vice versa. Unfortunately it also leads to massive duplication of data, including: - Fonts, both subsets and fully embedded fonts - Embedded ICC profiles, if present - Images re-used across multiple pages or documents In the case of images, ICC profiles, and fully embedded fonts it'd potentially be relatively easy to coalesce these so that all resources dictionaries refer to the same object. It's a little hacky because fop doesn't give image plugins any official way to store data about a rendering run for later reference, but it's easy enough to do by storing a WeakHashMapFOUserAgent,... associating object type and checksum data with a particular rendering run. I haven't implemented coalescing of images and profiles because it's not part of my problem space, but it shouldn't be too hard. Unfortunately, the above approach doesn't work for our problem, which is duplicated *subset* fonts. There are 20 or 30 copies of Helvetica Regular alone in one of our typical runs, with a mixture of MacRoman, Custom and WinAnsi encodings. They're drawn from the same two or three copies of Helvetica from different sources, but each subset has a different (though largely overlapping) glyph set. Fop-pdf-image correctly but rather sub-optimally copies each subset and references it from the associated Form XObject, creating working output but lots of wasted space and duplication. We can't just write the font out the first time we see it and adjust all future references to the copy we've already written, because unlike with ICC profiles and repeatedly used images each copy is different. I see two possible solutions to this problem. Both have the same pre-requisites: (1) A mechanism for image plugins to keep plugin-specific data associated with a specific rendering run. A WeakHashMapFOUserAgent,... works for this, though it isn't pretty. (2) Code in the image plugin to record each use of each font and group usages up into compatible groups so all font references in the group can point to the same font in the output. This code can also collect up glyph usage information, producing a map of which glyphs are required by one or more content streams. (3) A way to create a new embedded font in the output
Re: Fwd: Google Summer of Code
Font de-duping is intrinsically a post-process action, you need the full document, with all fonts, before you can do any font de-duping. PostScript does this very thing (to a much lesser extent) with the optimize-resources tag, as a post-process action. Also, the requirements aren't clear here, what is it we want here? Let me validate that, this shouldn't change the (I guess we can call it) canonical PDF document. By that I mean if you rasterized a PDF before and after this change they should be identical, pixel-for-pixel. When Acrobat does the font de-duping (I don't remember how much control it gives you, but if there are levels of de-duping I would have chosen the most aggressive), the documents aren't identical. There are aberrations caused by slight kerning differences between various verisons of Arial. This may seem trivial when compared to bloated PDFs, but it looks tacky and lowers the high standard of documents. You could argue this could be configurable... But then I'd re-iterate my first argument, this is a post-process action, not the concern of FOP or the pdf-image-plugin. The other issue is you have subset fonts created by FOP as well as those imported by the pdf-image-plugin. You'd have to create some bridge between the image loading framework and the font loading system *cough* HACK *cough*. Alternatively, just thinking aloud here, if this was done as a post-process *wink* *wink* *wry smile*... Apologies if I may seem to be argumentative here, it's not my intention, but I feel this is would be serious scope creep. I see the pdf-image-plugin as a plugin that treats PDFs as images, nothing more. If you want to stitch together PDFs, PDFBox is designed just for that. Mehdi On 6 March 2012 10:36, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 06/03/2012 10:12, mehdi houshmand wrote: I fat-fingered the reply button instead of reply-to-all... *face-palm* Mehdi, Craig, snip/ - Anything in the proposed XSL-FO 2.0 feature list (though most of it won't be realistic for GSoC projects); - Merge fop-pdf-image and implement smart merging of font, profile, and image resources. I'm working on this one at the moment, but slowly and only amid other projects. I really don't think that's a suitable project, I responded to your post so maybe we could take this conversation else where, but this really isn't FOPs responsibilty, or for that matter the pdf-image-plugin. If anything, I'd argue that's a PDFBox project, Adobe Acrobat Pro does this kind of thing (badly may I add) as a post-process action and I think that's the correct way to do it. The other thing to say is that a new comer may not appreciate the importance of fidelity when fonts are concerned. Basically it's too difficult for a student given a few months and no previous experience. Sorry Mehdi I don't agree. I think this would be a great project. Craig already outlined what needs to be done and theres a lot of stuff in XGC and FOP as well as the plug-in. I'm not sure anything is needed in PDF-Box, but even if it then is an Apache project too and the student can submit patches there. Adobe Acrobat may make some assumptions that don't always hold true, but our customers are crying out for FOP to create smaller PDF files when importing multiple PDF images with embedded fonts. This also feels reasonable well defined thanks to Craig's list of TODOs and feels like it can be done in 3 months. It gets a +1 from me. Thanks, Chris -- Craig Ringer
Re: Fwd: fop-pdf-image and fonts; as requested
Hi Craig, Excellent!!! I think we're making some progress here! snip Ugh. A well-designed RIP should be able to load XObject forms on demand and free them under memory pressure. After all, an image is also a global resource that can be referenced multiple times across different pages (an indirect object with a stream), but PDFs with large numbers of images don't typically crash RIPs. There's no excuse for lots of small indirect objects crashing a RIP, be they images or form xobjects. The operative word there is well-designed, but also, I think you're making a lot of assumptions about how the RIP handles these object. I don't disagree with your assumptions, but I'm just saying, you don't know how the RIP handles these objects so you have to be careful. snip/ The same is technically true of rendering a form XObject. Once you've drawn it, you can discard its content stream from memory and discard any resources you loaded from its resources dictionary. The trouble is that you don't know if you'll just be loading it again for the next page. It'd be fairly simple to keep a LRU list of form XObjects so they get unloaded if they're not referenced after a few pages are processed and there's memory pressure. I won't be too surprised if most RIPs don't do this, though. Yeah, again, assuming the people who designed the code designed it to be robust and flexible is a dangerous assumption I think. snip If you want to use PDFs as image-like resources within a page (as I do) then you can't just append the /Page object from the source PDF. As I understand it (I haven't implemented this) it's necessary to: * Extract the /Page's content stream(s) plus all resources referenced * Append the referenced resource(s) to the target page's resource dictionary, allocating new object numbers as you copy a resource and changing the target of any indirect references to match the new object number * Insert the concatenated content streams from the source PDF into the output content stream. They must be surrounded by appropriate graphics state save and restore operators and any necessary scale/position operations to place the content where you want it. HA HA!! Incorrect! If you look into the nooks and crannies of the PDF spec, you'll see that it's possible to use content stream arrays for the /Page content stream. I'll leave exploring that to you, but basically it makes overlaying pages much much simpler. In related news, PDFBox does just that!! What we did (and it's super hack, but it worked) is if there we pages with both PDF-image content and FOP generated content, we'd get FOP to generate the content without the PDF-image and just overlay the pages. Best of both worlds!! (Though the purist in me is very much aggrieved) Ok, so maybe I'll add some transparency as to how we came to some of these decisions. The client told us that PDFs ~16k pages with with 6-8k XObjects (I *heart* grep) were disproportionally slow and that fonts were to blame, so obviously that's where we started. I managed to do some font de-duping of Type1 fonts (seen as FOP doesn't subset these), it was horrendous, the fidelity was terrible but I was just experimenting. This made some impact, but not enough. So after some more experimentation, proving fonts weren't to blame, we had to step back and look at the problem again. We also, found out that the RIP times didn't correlate to the size of the document i.e. x pages takes y time, 2x was taking 10y time (if that makes sense). This made us think it was a memory issue, some how the RIPs memory was filling up. A lot of faffing about later, and we got to the conclusions I've described. The more you describe your problem, the more it sounds like you need to do exactly what we did, but just to be sure, I thought I'd explain how we got there. Assumptions are a dangerous thing and I've probably made some about your issue too. Hopefully we can get to some resolution about this soon, Mehdi
Re: Fwd: fop-pdf-image and fonts; as requested
Haha, well the shortest answer I can give is kinda. SVG uses Batik, which in turn uses the AWT font classes. Long story short, you have to install the font on the system as well as having it in the fop.xconf. There are plenty of discussions on this on the mailing lists for you to peruse at your leisure. Mehdi On 8 March 2012 02:17, Craig Ringer ring...@ringerc.id.au wrote: On 08/03/12 04:12, Vincent Hennebert wrote: Just my 2 cents on a particular detail... On 07/03/12 07:51, Craig Ringer wrote: On 06/03/12 18:49, mehdi houshmand wrote: snip/ So with that in mind, what exactly are you trying to do? Why are you using FOP to merge PDFs? I'm using FOP to produce documents containing a mixture of automatically typeset formatted text and graphics. Many of the graphics are PDF documents, and need to be PDF documents because they contain vector artwork and text that would lose quality and grow massively in size if embedded in rasterised form. Is SVG an option for you? That might save you a lot of trouble. Or if not readily available, that might still be less work. Alas, SVG isn't an option. We have a large body of work already in PDF (and EPS) format that we can't easily convert to SVG. Until I checked just now I didn't know that SVG even supported embedded fonts. Does fop actually support that and include embedded SVG fonts in output PDF? -- Craig Ringer
Re: Merging Temp_PDF_ObjectStreams branch to trunk
If I'm not mistaken the r1302518 commit broke compile compatibility with the Jeremias' PDF-image-plugin trunk which needs to be addressed. It's a simple change if I'm not mistaken, just to do with how PDFDocument holds it's version (was an int now an enum o.a.f.pdf.Version), there maybe some other minor changes, but that one sticks out. Anyway, I haven't checked it myself, but trust yourself and Pete did a good job, +1 from me Mehdi On 21 March 2012 15:40, Vincent Hennebert vhenneb...@gmail.com wrote: Hi All, I’ve just uploaded our work on PDF object streams. If accessibility is enabled and PDF version 1.5 has been selected in the config file, then the structure tree will be stored in object streams. Support for cross-reference streams (a successor of the cross-reference table that appeared in 1.5) has been implemented in order to be able to address objects stored in object streams. The amount of space saved can be substantial, as much as 70% on a 20-page document. The changes are relatively localized and mostly affect the PDF packages. While there are significant refactorings, there is not a lot of new code. Therefore I’m inclined to handle this using lazy consensus; So if nobody objects within 72 hours, I’ll merge the branch back to trunk. Side note for those using the PDF Images plug-in: once the branch has been merged, the plug-in will have to be modified so that PDF objects do not output the obj/endobj wrapper themselves if they are indirect. This concerns the PDFBoolean and PDFString classes in o.a.f.render.pdf.pdfbox. Also, AbstractPDFStream now uses composition rather than inheritance for its dictionary, which requires changes to PDFBoxAdapter. Once the PDF Images plug-in has been moved under the umbrella of the XML Graphics project, we will upload the necessary changes. Thanks, Vincent
Re: Caching xml.xsd [was: [GUMP@vmgump]: Project xml-fop-test (in module xml-fop) failed]
Yaaayy!! Thanks Vincent. Much appreciated! Mehdi On 23 March 2012 17:40, Vincent Hennebert vhenneb...@gmail.com wrote: I fixed the issue by copying the definition of xml:space into the IF schema. See http://svn.apache.org/viewvc?rev=1304524view=rev Vincent On 24/02/12 15:29, Vincent Hennebert wrote: On 16/02/12 10:23, mehdi houshmand wrote: Hi, I was running o.a.f.intermediate.IFParserTestCase in Eclipse, and found it extremely frustrating that the schema (xml.xsd) had to be in the same folder as the test class?!?! Why? It means, if I want to run said test with the Eclipse Junit Runner, I have to copy it into the proper directory, manually. ‘ant setup-xml-schema’ does that for you and you should have to run it only once per local copy. In related news, when I run ant junit, it chokes every time for a minute on checking the cached xsd file. I mean, it's obviously not the end of the world, but it is annoying and I'm questioning if it's necessary? I’m facing the same issue and it’s certainly suboptimal. I’m still unsure about the proper way to solve it though. Gump fails, periodically because of this same issue, which is annoying at best, and quite dangerous since false positives on a CI server... I don't need to preach to the choir here. Can we not assume that the normal W3C software license [1] applies here? If not, their document license [2]? If so, as per the Apache legal recommendations [3], we're thumbs up for distributing this file (with the notice). If either of those assumptions aren't valid, I'd be happy to ask the Apache legal team, they can at least resolve the ambiguity about the license. Just wanted to know your thoughts? This has been bugging me for a while... I investigated the issue again some time ago and couldn’t reach any definite conclusion. AFAICT the XML schema is published under the W3C Document License, due to the absence of explicit notice and as per [1]. I don’t think it’s covered by the W3C Software License because that would allow to modify the schema and would kill the purpose of the standard (the ‘interoperability problems’ mentioned in [1]). ATM and AFAICT, it’s unclear whether we are allowed to publish material under the W3C Document License. I’ve been watching the two following legal issues on JIRA but they haven’t been resolved yet: https://issues.apache.org/jira/browse/LEGAL-109 https://issues.apache.org/jira/browse/LEGAL-111 At any rate, ATM we don’t comply with the requirements prescribed by the W3C Document License [2]. Yet we have a copy of xml.xsd in src/documentation/intermediate-format-ng. I think we cannot release FOP until this has been resolved. As for a solution, the simplest probably is to rewrite the part of the XML schema that is of interest to us. This may be as simple as rewriting the definition of xml:space, but I haven’t tested it. [1] http://www.w3.org/Consortium/Legal/IPR-FAQ-2620#Which [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 Vincent Mehdi [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 [2] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.html [3] http://www.apache.org/legal/resolved.html#category-a On 10 November 2011 12:20, Vincent Hennebert vhenneb...@gmail.com wrote: On 10/11/11 09:31, Simon Pepping wrote: It is not a good idea to fetch xml.xsd from W3C each time. Put it in the sources and if necessary use a catalog. xml.xsd is already available at src/documentation/intermediate-format-ng/xml.xsd. Hmmm. Apparently Gump deletes the workspace directory before every build, which pretty much kills the benefits of the caching process that I had put in place in rev. 1186858. FWIW, I did have in mind to use a catalog, but AFAICT the catalog-based resolver available from XML Commons Resolver is not compatible with what is used by XML Schema (org.w3c.dom.ls.LSResourceResolver vs org.xml.sax.EntityResolver or javax.xml.transform.URIResolver). Also, using a catalog seemed a bit overkill for this. Storing xml.xsd locally is an option, but: • we lose the link to http://www.w3.org/2001/xml.xsd (although I suppose we can say that it’s obvious from looking at the content of the file) • if the original schema ever gets updated, we get out of sync (although I suppose that’s unlikely to happen) • most of all, are we allowed to redistribute this file? I couldn’t find any license information with it. For those reasons I chose to download it into some cache directory. I could remove this caching mechanism and point to src/documentation/intermediate-format-ng/xml.xsd instead, if bullet 3 above is not an issue. Thoughts? Thanks, Vincent Simon On Thu, Nov 10, 2011 at 08:27:53AM +, Jeremias Maerki wrote: To whom it may engage
Re: resolved, fixed bugs since FOP1.0 that need to be closed
I wouldn’t bother. Lacking of a proper QA process, we don’t use the ‘verified’ and ‘closed’ status and consider that a bug has been handled once its status has been changed to ‘fixed’. Vincent Not sure I agree with you there Vincent. Giving a bug a closed status allows us to perform queries, as Glenn has, to see what patches are left outstanding and what needs to be applied. It also gives creates a necessary disparity between a [PATCH] which has Resolved and Fixed status, and when that patch has been applied. Also, we are always going to lack the proper QA process so I'm not sure that argument is valid. Mehdi
Re: A proposal to change the configuration and deployment of FOP
Hi Jeremias/Chris, First thing first; I'll second Jeremias's suggestion and Chris in saying that this is definitely a major release. The best reason is because we're purposefully changing behaviour. FOP is currently very flexible in handling URIs, it has a lot of contingency mechanisms for falling back if a file can't be found. These are great when FOP is invoked on the commandline, however, they have to be controlled in a cloud environment and unauthorised file access cannot be allowed. If users are relying on these contingencies, then they're going to find they have issues and I think that's a compelling reason for calling it a major change. Jeremias, as for being unconvinced about the necessity of making these API changes, I'd say it's a shame you didn't hear the conversations we had here about it. I started this body of work a while ago, and took a lot of steps to avoid changing the API for 2 reasons: 1) The reasons you gave above 2) We're changing FOPs behaviour, changing the API as well, I was afraid the community wouldn't support so many changes. I'm not sure if this is an acceptable reason or not, but it played a big part in my thought process. However, it's just not feasible to unify URI resolution to a single mechanism to be used in a highly parallelised system if there is mutability in the member variables. Mutability in FopFactory means that FOP isn't thread-safe, changing the FopFactory in one thread could have repercussions in other threads, so we had to lock this down. Because there's some set up in FopFactory that requires I/O, the base-URI and the URI resolver have to be available from the start, from initialization of FopFactory. Unfortunately it's that simple. And we thought, since we're changing the API in an incompatible way (adding parameters to FopFactory.newInstance(...), we might as well take this time to update and improve the way FopFactory is built. The biggest problem being the disparity between when FopFactory is setup using a populated fop.xconf, an empty fop.xconf and no fop.xconf. The way we've implemented it, the API isn't actually changing very much, there're about 2/3 lines of code changes depending on if you're using a fop conf or not. The only thing I have left to say is that the system just wasn't designed for what we're asking it to do now. When FopFactory was written, clouds were in the sky and SaaS was a typo. For better or worse though, that's where the industry is putting its resources and if we want FOP to remain relevant, we've got to keep up with it. I know I'm preaching to the choir here, but we feel these changes are an improvement and they are a necessary part of the task. When we push up the changes to the temp branch, hopefully you'll be much more convinced that what we've done is a) an improvement and b) necessary. Mehdi On 2 April 2012 13:46, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 01/04/2012 15:47, Jeremias Maerki wrote: Hi Jeremias, Thanks for your feedback. I'm answering in place of Peter who is on holiday this week. Thanks for elaborating, Peter. Your use of the term deployment is indeed rather unorthodox. When I read deployment, I instantly think: http://en.wikipedia.org/wiki/**Software_deploymenthttp://en.wikipedia.org/wiki/Software_deployment I'm afraid you still haven't convinced me of the necessity to break the public API even if, as you say, it's only a minimal change. It's the difference between being able to upgrade FOP with a replacement of a JAR and the process of adjusting glue code to the changes, testing and re-releasing them. Obviously, you'll still have to test your documents with a release change. However, integrators such as OxygenXML, XMLSpy, Stylus Studio, XMLmind, XSLfast, Apache Cocoon and many others have to change their products again to be able to use the new FOP version. Their clients cannot just switch JARs. I can tell tales about how many hours I've spent porting/duplicating the Barcode4J extension for Saxon many times because the plug-in API changed even within minor revisions. Ultimately, I stopped trying to keep up. I'm sure you get the drift. I see your point. I don't think FOP would suffer from the same issue as we only tend to release every other year or so :-) I do agree that we need to minimize the changes to the public API, but in this case there is a good reason for a small amount of change. We are making FOP suitable for a cloud environment and to do that requires quite a few internal as well as some minor external changes to the URI Resolvers. It's true that it could be made to work without any change to the FOPFactory API, but the current situation seems sub-optimal and since we would have to change the URI Resolvers which are part of the API then why not do this at the same time rather than delay it until later? If there was a case of: if we don't break the public API, then we can't do X, I would understand the desire for such a step, but I'm not
Re: A proposal to change the configuration and deployment of FOP
Hi Glenn, Firstly, although this is loosely related, can you try to keep the emails in the thread relevant, this is going to be a verbose thread so we don't want to add to the confusion. As for the public API, I don't believe IFPainter is part of the public API, but I'm not sure who does and doesn't agree. I wrote that wiki page in hope that we'd come to some consensus, but it just moved from the fore of conversation, looks like we're back there. Mehdi On 2 April 2012 16:24, Glenn Adams gl...@skynav.com wrote: On Mon, Apr 2, 2012 at 9:15 AM, Glenn Adams gl...@skynav.com wrote: On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki d...@jeremias-maerki.ch wrote: There must be a really, really good reason to change the frontmost public API of FOP in a backwards-incompatible way. Changing the API will cause considerable work for all users when they upgrade. We must not do that on a whim. Would you consider a minor, but substantive technical change to the IF APIs, specifically, to IFPainter, to require a revision of the major version? I ask this because one of the arguments to IFPainter.drawText() has been changed from int[] to int[][] in the recent complex scripts merge. In other words, are the IF public APIs to be considered part of the formal public FOP API that is subject to version control rules? Do we have a precise list of which APIs are (or should be) subject to such rules? I found http://xmlgraphics.apache.org/fop/trunk/embedding.html#API But I see this doesn't list IFPainter, even though IFDocumentHandler.startPageContent() returns an IFPainter. Also, I should mention that the CS patch made two minor, but substantive changes to the IF schema (and thus output format). Should changes to the IF schema also be subject to public version control rules?
Re: Assigning unique resource names
Hi Craig, My sincerest apologies for not getting round to looking at what you've done here. I'll try and take a look in the next few days and give it a think, see if there's anything we can do to help. Apologies once again, Mehdi On 28 March 2012 07:39, Craig Ringer ring...@ringerc.id.au wrote: Hi I've nearly finished work on getting fop-pdf-image to overlay PDFs by appending their content streams and merging their resource dictionaries, rather than by creating XObject Forms. The problem I have left will be more intrusive into the fop codebase than what I've had to do so far, so I thought I'd check in before I start working on it. The reason I'm adapting fop-pdf-images to support merging PDF images into the main PDF content instead of using XObject Forms is that the use of lots of PDF XObject Forms seems to cause RIPs and clients to perform poorly or run out of memory. The way I propose to do it, fop-pdf-images will use an XObject form if the preloader sees a pdf image re-used more than a configurable number of times (one by default), and otherwise merge it into the main pdf. Most of that is done, but there's a problem with ensuring unique resource names. XObject Form resource dictionaries are their own namespace, so no resource name (font, ExtGState, etc) in an XObject Form may conflict with a name in the parent page's resource dictionary. If XObject Forms are no longer used by fop-pdf-image, that namespace separation goes away. I have to merge the image page(s)'s resource dictionaries into the resource dictionary of the page they're being overlaid over. In the case of fop, that's the global resource dictionary because fop doesn't currently write per-page resource dictionaries. There's nothing wrong with this beyond potentially making the resource dictionary a bit fat, but it means I need a way to guarantee that a name will not conflict with any other name assigned by fop. For GState dictionary objects that's easy; fop just uses GS+object number as the name, so if I follow the same scheme when copying resources I'm guaranteed to get a unique name since object numbers are unique. Unfortunately, fop doesn't do anything so consistent for fonts or most other resources, and that's made it nearly impossible for me to guarantee that I can use a name without a later part of the XSL-FO causing fop to create an object that tries to use the same name. Solving this will require some changes to the way fop writes the PDF resources dictionary. I propose that the PDFResources class should take responsibilty for allocating resource names and ensuring they're consistent. Instead of asking each resource what its name is, the PDFResources class should *assign* it a name. Those names can be minimal and compact - eg Fnn for fonts, GSnn for graphics states, etc. nn would be a counter maintained by PDFResources. That's the convention followed by most other PDF producing software and would make it simple and reliable to inject objects not created by fop into the resources dictionary without risk of conflicts. That'll be important if people want to be able to write extensions that add new, custom PDF content; it's not just useful for fop-pdf-images. This API change would only affect extensions, services and clients that work directly with org.apache.fop.pdf. and org.apache.fop.render.pdf. classes, and only some of those. Clients that use the main fop APIs would be completely unaffected, as would clients that use the area tree / IR code, image loader code, or pretty much anything except the guts of pdf handling. I'll post a proposed patch soon, along with patches for some other changes that enable what I'm doing but may be useful for others. A patch with the fop-pdf-images merge feature support will follow once I've finished it enough that I can do test-runs. -- Craig Ringer
Re: A proposal to change the configuration and deployment of FOP
Hi Jeremias,
I'll add my comments inline:
snip/
First, I'd like to stress that I'm not putting out a veto here. I'm
just trying to take the position of an advocate to the FOP users who
might not all follow the development closely.
Yeah, I/we do appreciate your concerns, it's important for any body of work
to stand up to scrutiny. We need your (both personal and the collective
your) experience and expertise to critique our work not only so that we
maintain the high quality of FOP, but to improve ourselves as developers.
Back on the technical side: A JAXP TransformerFactory is just as mutable
as the FopFactory, but only if it's handled wrongly by the developer of
the client code. In the application I'm currently working on, the
FopFactory is created once based on the configuration and registered as
an OSGi service. All client code using the FopFactory (service) is
written as if the FopFactory is immutable. Yes, I'm counting on the
participants to play nice although I can still proxy the FopFactory if
need be. And my application is also targeted to be deployable in the
cloud (I hate that wishy-washy term) and already works with zero access
to the local file system.
I ask you this; how are we defining work? The caveats we imply and
assumptions we make aren't trivial. Are we talking about just producing
plain vanilla documents with no custom fonts and no images? Sure, works
like a dream. Or are we talking about very strict I/O such that no user can
either intentionally/unintentionally access someone else's resources under
ANY circumstances? Well... No. I'm just not confident that it would be
possible to guarantee that level of security.
Having immutability in the FopFactory allows us to make assertions, it
prevents if (x == null) { x = default value } all over the shop.
So to be frank, I still see squeeky clean, best practice design (which
is in itself nothing but good) being put before continuity (or API
stability) without an absolute need for an API break to enable
cloud-compatibility. And I personally weigh API stability higher than
design principles. The world isn't perfect. However, I see no problem
improving the URI resolution the way you propose it as long as it is
done in a backwards-compatible way. Again, no veto, just my opinion. I
might be the only one here who sees it that way.
snip/
Well again, we're breaking the API anyways! Because FopFactory relies on
I/O for setup (the font-cache, and the fop-conf if it is used, the latter
I'll discuss in more detail), we need both a base-URI and a URI resolver
when the FopFactory is instantiated. There's not a lot we can do about
that, we can't have FOP accessing the user.dir in the cloud. There is an
argument to be made that we disallow fonts-caching, but then we're not
solving the problem, we're de-scoping.
As for the fop-conf, if it is used, keeping the old mechanism, a client
would have to do the following:
FopFactory f = FopFactory.newInstance();
f.setUriResolver(...);
f.setUserConfig(...);
If they didn't set the URI resolver *before* setting the user config, then
they're going to see different behaviour. Also if the did this:
FopFactory f = FopFactory.newInstance();
f.setUriResolver(...);
f.setUserConfig(...);
f.setUriResolver(...); -- different URIResolver used here!
then they're gonna see even more unusual behaviour, since there's a
disparity between the URIResolver used set to configure the FopFactory and
that used to configure the PrintRenderers. A friend of mine once said to me
you can use all your wit to make things idiot-proof and an idiot will come
along and out-smart you, and I very much agree you can't protect against
every quirky use-case. But the above just doesn't seem right to me. If an
object is used for configuring and initializing a class, it should be in
the constructor.
Thanks for your patience Jeremias, it really is appreciated,
Mehdi
Re: Assigning unique resource names
Hi Craig, I'll address each of your suggestions inline: snip/ The reason I'm adapting fop-pdf-images to support merging PDF images into the main PDF content instead of using XObject Forms is that the use of lots of PDF XObject Forms seems to cause RIPs and clients to perform poorly or run out of memory. The way I propose to do it, fop-pdf-images will use an XObject form if the preloader sees a pdf image re-used more than a configurable number of times (one by default), and otherwise merge it into the main pdf. How do you plan to make this configurable? From the fop.xconf? I think we may want to do either ALL XObjects or ALL overlaid pages, adding configurability here doesn't really add anything that I can see. snip/ Unfortunately, fop doesn't do anything so consistent for fonts or most other resources, and that's made it nearly impossible for me to guarantee that I can use a name without a later part of the XSL-FO causing fop to create an object that tries to use the same name. Solving this will require some changes to the way fop writes the PDF resources dictionary. Presumably you're a talking about the PDFName which holds a reference to the Font (i.e. /Font /F1 X 0 R - where X is the object number)? I propose that the PDFResources class should take responsibilty for allocating resource names and ensuring they're consistent. Instead of asking each resource what its name is, the PDFResources class should *assign* it a name. Those names can be minimal and compact - eg Fnn for fonts, GSnn for graphics states, etc. nn would be a counter maintained by PDFResources. That's the convention followed by most other PDF producing software and would make it simple and reliable to inject objects not created by fop into the resources dictionary without risk of conflicts. Again, by font name I presume you're meaning the one I describe above. If you are, then that's fine. If you're meaning the actual /FontName parameter within the /FontDescriptor then no, you can't do that. For the latter the PDF spec is quite clear about it's expectations having a tag prefix the font name and also, if you didn't already know, font subsets must have unique /FontName properties. By unique, I don't mean unique in the general sense; only that they must be unique within the document. Just something to be aware of. This API change would only affect extensions, services and clients that work directly with org.apache.fop.pdf. and org.apache.fop.render.pdf. classes, and only some of those. Clients that use the main fop APIs would be completely unaffected, as would clients that use the area tree / IR code, image loader code, or pretty much anything except the guts of pdf handling. I'll post a proposed patch soon, along with patches for some other changes that enable what I'm doing but may be useful for others. A patch with the fop-pdf-images merge feature support will follow once I've finished it enough that I can do test-runs. Excellent, I look forward to seeing your patch! Sorry it's taken so long to respond to this, but do let me know if you need any help. Mehdi
Re: [VOTE] Switch from Bugzilla to JIRA
Hi, I'm sceptical the cost/rewards add up, but since Glenn has volunteered for all the hard work, then there're no costs and only rewards :)!! It'll be an onerous task and the usually a thankless one, so I'll address the latter by saying thanks Glenn! +1 from me Mehdi On 17 April 2012 09:15, Chris Bowditch bowditch_ch...@hotmail.com wrote: Hi All, We need to have a formal vote to decide if the XML Graphics project and all sub projects should switch the bug tracking system from Bugzilla to JIRA. The main benefits of which are: 1. JIRA has a more modern look and feel 2. Infrastructure are not equiped to support Bugzilla anymore as most Apache projects are based on JIRA. Therefore should be more able to respond to requests for changes. The downside is that someone will have to work with infra@ to organize the import of bugs from BZ to JIRA. We then need to update the website links to point to JIRA instead of BZ. Glenn Adams has kindly volunteered to oversee the migration. Heres my +1 The vote runs until 24th April. Thanks, Chris
Re: svn commit: r1337142 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/afp/fonts/ src/java/org/apache/fop/afp/modca/ src/java/org/apache/fop/afp/ptoca/ test/java/org/apache/fop/afp/ptoca/
This isn't a significant change, it just changes the max TRN size for a DBCS to 252 rather than 253 for SBCSs. The rest of the patch is just clean up, I don't think it warrants a bug really... On 11 May 2012 14:40, Glenn Adams gl...@skynav.com wrote: was there a bug filed against which this fix was made? it's useful to always file a bug for a significant change On Fri, May 11, 2012 at 3:14 PM, me...@apache.org wrote: Author: mehdi Date: Fri May 11 13:14:17 2012 New Revision: 1337142 URL: http://svn.apache.org/viewvc?rev=1337142view=rev Log: Changed the way AFP PTOCA TransparentData control sequences are written so that they end on character byte boundaries
Re: svn commit: r1338605 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/afp/fonts/ src/java/org/apache/fop/afp/ptoca/ src/java/org/apache/fop/render/afp/ test/java/org/apache/fop/afp/fonts/
Yeah fair play on this one, in all honesty I was being lazy this time. On 15 May 2012 15:42, Glenn Adams gl...@skynav.com wrote: Could you file a bug and reference it against this commit? Most commits that change code, except perhaps one that is a trivial fix to a immediately prior checkin or a cleanup fix, should have a bug filed that corresponds to the commit. That allows us to have a better document trail for the commit, one purpose of which is to summarize the commit at the time of next release. From the commit message below, I have no idea what this commit does specifically. So when it comes time for a release, I expect it will not be summarized, or the summary will be equally non-descript. On Tue, May 15, 2012 at 3:07 AM, me...@apache.org wrote: Author: mehdi Date: Tue May 15 09:07:02 2012 New Revision: 1338605 URL: http://svn.apache.org/viewvc?rev=1338605view=rev Log: Improved handling of AFP double-byte character sets
[no subject]
Hi All, I think we've got to the stage in the URI unification branch where it's ready to be merged into trunk (not into 1.1RC1). I know there have been proponents against the inclusion of this feature and/or those who are concerned the wider implications as it means FOP has fewer contingency methods when attempting file access. I'll try and explain how we've addressed those concerns as well as some of the code improvements we've made. - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous i.e. contains white-space, \ instead of /, we do some validation on to mitigate some of the common mistakes. However, we don't allow for falling back to 'new File(.)' or new URL(...).openStream() since these can obviously cause clashes in a highly parallelised multi-tenant environment. - Single FOP conf parse - Previously the renderer specific regions of the FOP conf was being parsed on every run. This is costly to performance for the obvious reason, but as well as this, it meant that font auto-detection was having to be executed on every run. The font-caching was created to mitigate some of those performance costs, however, caching the FOP conf makes much more sense. It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. The renderer specific config is also lazy loaded such that it is only parsed when the respective renderer is invoked, mitigating the one-off cost of parsing that config. - The environment profile - We've created an environment profile that abstracts the system in which FOP is invoked. This allows us to programmatically enforce restrictions to, for example, font-caching and auto-detection since users may want to control this behaviour for any number of reasons. - Improved URI handling - because the URI resolution has been unified to a couple of classes, the behaviour is much easier for users to understand. - Consistent base directories - We've tried to ensure that base directories are consistent with FOP previously, the base and font-base still work as previously. There are however some outstanding TODOs that need to be addressed, however, though they are important, they don't need to be all merged in at the same time. I will be working on these and keep the community updated: TODOs// - XGC and libraries - This is most likely the next project, we need to do the same in the XGC project and look at some of FOPs dependencies (Batik too!). The plan will be to move all the resource resolver classes to XGC since that is the parent library so that they can be used though out the XMLGraphics libraries. - Improved MIME type resolution - currently FOP's file-type (file-MIME-type) is performed in-situ using file-name endings. This is, while working perfectly fine on a desktop environment, would be less than desirable if file-names were just hashes or the like from a virtual file-system. We need to give the user the flexibility to define a file MIME type without forcing them to put the file-ending in the URI. - Default handling in some of the Configurators - We have improved the mechanism that handles default values in the configuration as well as config injected via RendererOptions (on the FOUserAgent) and the FOP conf for PDF. However, time constraints haven't allowed us to do the same for PS and AFP, which would be nice to do. This isn't of utmost priority, but it would be nice to not have the if (x != null) peppered around the source Sorry for the long email, I just thought it'd be a good time to expose some of the work we've been doing, Mehdi P.S. More information can be found wiki under the developers section, it's currently down so I can't post a link.
[VOTE] Merge Temp_URI_Unification
Sorry, added [VOTE] to subject line... My bad On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com wrote: Hi All, I think we've got to the stage in the URI unification branch where it's ready to be merged into trunk (not into 1.1RC1). I know there have been proponents against the inclusion of this feature and/or those who are concerned the wider implications as it means FOP has fewer contingency methods when attempting file access. I'll try and explain how we've addressed those concerns as well as some of the code improvements we've made. - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous i.e. contains white-space, \ instead of /, we do some validation on to mitigate some of the common mistakes. However, we don't allow for falling back to 'new File(.)' or new URL(...).openStream() since these can obviously cause clashes in a highly parallelised multi-tenant environment. - Single FOP conf parse - Previously the renderer specific regions of the FOP conf was being parsed on every run. This is costly to performance for the obvious reason, but as well as this, it meant that font auto-detection was having to be executed on every run. The font-caching was created to mitigate some of those performance costs, however, caching the FOP conf makes much more sense. It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. The renderer specific config is also lazy loaded such that it is only parsed when the respective renderer is invoked, mitigating the one-off cost of parsing that config. - The environment profile - We've created an environment profile that abstracts the system in which FOP is invoked. This allows us to programmatically enforce restrictions to, for example, font-caching and auto-detection since users may want to control this behaviour for any number of reasons. - Improved URI handling - because the URI resolution has been unified to a couple of classes, the behaviour is much easier for users to understand. - Consistent base directories - We've tried to ensure that base directories are consistent with FOP previously, the base and font-base still work as previously. There are however some outstanding TODOs that need to be addressed, however, though they are important, they don't need to be all merged in at the same time. I will be working on these and keep the community updated: TODOs// - XGC and libraries - This is most likely the next project, we need to do the same in the XGC project and look at some of FOPs dependencies (Batik too!). The plan will be to move all the resource resolver classes to XGC since that is the parent library so that they can be used though out the XMLGraphics libraries. - Improved MIME type resolution - currently FOP's file-type (file-MIME-type) is performed in-situ using file-name endings. This is, while working perfectly fine on a desktop environment, would be less than desirable if file-names were just hashes or the like from a virtual file-system. We need to give the user the flexibility to define a file MIME type without forcing them to put the file-ending in the URI. - Default handling in some of the Configurators - We have improved the mechanism that handles default values in the configuration as well as config injected via RendererOptions (on the FOUserAgent) and the FOP conf for PDF. However, time constraints haven't allowed us to do the same for PS and AFP, which would be nice to do. This isn't of utmost priority, but it would be nice to not have the if (x != null) peppered around the source Sorry for the long email, I just thought it'd be a good time to expose some of the work we've been doing, Mehdi P.S. More information can be found wiki under the developers section, it's currently down so I can't post a link.
Re:
I meant that font-caching wasn't necessary so if you disable it, it wouldn't have a performance impact in a batch processing system like a cloud environment. I should make it clear that we haven't removed either font-caching or font auto detection, we have just given users the means to disable and/or restrict those services. Mehdi On 26 June 2012 15:57, Glenn Adams gl...@skynav.com wrote: On Tue, Jun 26, 2012 at 8:38 AM, mehdi houshmand med1...@gmail.comwrote: It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. I'm not sure I understand what you mean by we can get rid of font-caching. Does this work eliminate font caching or are you suggesting that it makes such a change more feasible. Or by get ride of do you mean disable?
Re: [VOTE] Merge Temp_URI_Unification
Hi Pascal, I won't be merging this into anything other than trunk. Sorry, maybe I should have made that more explicit. Mehdi On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote: Hi, +1 for merging it to trunk. That said, I'm a little puzzled with the release process. In my mind, a RC should come before a production release, freezing all features. Only bugfix should be permitted on RC. Adding new feature to RC2 is a precedent that allows to add a new feature after each RC, witch need to release a new... RC, etc. I humbly suggest that the release process start with a 1.1 branch, from witch RCx and final release will be tagged, that should allow to continue merging branches onto trunk without any interaction on branch release. WDYT? 2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com: On 26/06/2012 15:39, mehdi houshmand wrote: Sorry, added [VOTE] to subject line... My bad +1 from me. Good work Mehdi and Pete. Chris On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: Hi All, I think we've got to the stage in the URI unification branch where it's ready to be merged into trunk (not into 1.1RC1). I know there have been proponents against the inclusion of this feature and/or those who are concerned the wider implications as it means FOP has fewer contingency methods when attempting file access. I'll try and explain how we've addressed those concerns as well as some of the code improvements we've made. - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous i.e. contains white-space, \ instead of /, we do some validation on to mitigate some of the common mistakes. However, we don't allow for falling back to 'new File(.)' or new URL(...).openStream() since these can obviously cause clashes in a highly parallelised multi-tenant environment. - Single FOP conf parse - Previously the renderer specific regions of the FOP conf was being parsed on every run. This is costly to performance for the obvious reason, but as well as this, it meant that font auto-detection was having to be executed on every run. The font-caching was created to mitigate some of those performance costs, however, caching the FOP conf makes much more sense. It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. The renderer specific config is also lazy loaded such that it is only parsed when the respective renderer is invoked, mitigating the one-off cost of parsing that config. - The environment profile - We've created an environment profile that abstracts the system in which FOP is invoked. This allows us to programmatically enforce restrictions to, for example, font-caching and auto-detection since users may want to control this behaviour for any number of reasons. - Improved URI handling - because the URI resolution has been unified to a couple of classes, the behaviour is much easier for users to understand. - Consistent base directories - We've tried to ensure that base directories are consistent with FOP previously, the base and font-base still work as previously. There are however some outstanding TODOs that need to be addressed, however, though they are important, they don't need to be all merged in at the same time. I will be working on these and keep the community updated: TODOs// - XGC and libraries - This is most likely the next project, we need to do the same in the XGC project and look at some of FOPs dependencies (Batik too!). The plan will be to move all the resource resolver classes to XGC since that is the parent library so that they can be used though out the XMLGraphics libraries. - Improved MIME type resolution - currently FOP's file-type (file-MIME-type) is performed in-situ using file-name endings. This is, while working perfectly fine on a desktop environment, would be less than desirable if file-names were just hashes or the like from a virtual file-system. We need to give the user the flexibility to define a file MIME type without forcing them to put the file-ending in the URI. - Default handling in some of the Configurators - We have improved the mechanism that handles default values in the configuration as well as config injected via RendererOptions (on the FOUserAgent) and the FOP conf for PDF. However, time constraints haven't allowed us to do the same for PS and AFP, which would be nice to do. This isn't of utmost priority, but it would be nice to not have the if (x != null) peppered around the source Sorry
Re: [VOTE] Merge Temp_URI_Unification
Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*? The 1.1 branch has already been defined and voted upon, I don't see how any changes to trunk would affect it? I'm not very familiar with the FOPs releasing process so do excuse me. Mehdi On 2 July 2012 13:42, Pascal Sancho psancho@gmail.com wrote: Mehdi, I speak about post 1.1RC1. Your merge will be against the trunk. What about the 1.1RC2 or 1.1 final? In the current usage, *all* FOP releases are tagged directly from trunk (via a branch that is only to set FOP version and lib dependencies). So, every further RC or final releases are planed to be ma 2012/7/2 mehdi houshmand med1...@gmail.com: Hi Pascal, I won't be merging this into anything other than trunk. Sorry, maybe I should have made that more explicit. Mehdi On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote: Hi, +1 for merging it to trunk. That said, I'm a little puzzled with the release process. In my mind, a RC should come before a production release, freezing all features. Only bugfix should be permitted on RC. Adding new feature to RC2 is a precedent that allows to add a new feature after each RC, witch need to release a new... RC, etc. I humbly suggest that the release process start with a 1.1 branch, from witch RCx and final release will be tagged, that should allow to continue merging branches onto trunk without any interaction on branch release. WDYT? 2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com: On 26/06/2012 15:39, mehdi houshmand wrote: Sorry, added [VOTE] to subject line... My bad +1 from me. Good work Mehdi and Pete. Chris On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: Hi All, I think we've got to the stage in the URI unification branch where it's ready to be merged into trunk (not into 1.1RC1). I know there have been proponents against the inclusion of this feature and/or those who are concerned the wider implications as it means FOP has fewer contingency methods when attempting file access. I'll try and explain how we've addressed those concerns as well as some of the code improvements we've made. - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous i.e. contains white-space, \ instead of /, we do some validation on to mitigate some of the common mistakes. However, we don't allow for falling back to 'new File(.)' or new URL(...).openStream() since these can obviously cause clashes in a highly parallelised multi-tenant environment. - Single FOP conf parse - Previously the renderer specific regions of the FOP conf was being parsed on every run. This is costly to performance for the obvious reason, but as well as this, it meant that font auto-detection was having to be executed on every run. The font-caching was created to mitigate some of those performance costs, however, caching the FOP conf makes much more sense. It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. The renderer specific config is also lazy loaded such that it is only parsed when the respective renderer is invoked, mitigating the one-off cost of parsing that config. - The environment profile - We've created an environment profile that abstracts the system in which FOP is invoked. This allows us to programmatically enforce restrictions to, for example, font-caching and auto-detection since users may want to control this behaviour for any number of reasons. - Improved URI handling - because the URI resolution has been unified to a couple of classes, the behaviour is much easier for users to understand. - Consistent base directories - We've tried to ensure that base directories are consistent with FOP previously, the base and font-base still work as previously. There are however some outstanding TODOs that need to be addressed, however, though they are important, they don't need to be all merged in at the same time. I will be working on these and keep the community updated: TODOs// - XGC and libraries - This is most likely the next project, we need to do the same in the XGC project and look at some of FOPs dependencies (Batik too!). The plan will be to move all the resource resolver classes to XGC since that is the parent library so that they can be used though out the XMLGraphics libraries. - Improved MIME type resolution - currently FOP's file-type (file-MIME-type) is performed in-situ using file-name endings
Re: [VOTE] Merge Temp_URI_Unification
Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little there ;) Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this burdens you in some way, could you let me know how and maybe we can come to some resolution? As far as I can see, it shouldn't affect the 1.1rc1 branch at all. Mehdi On 2 July 2012 14:19, Pascal Sancho psancho@gmail.com wrote: Sorry Mehdi, I realize that I started a new discussion. Merging your development branch onto the trunk is not what puzzled me. This has to be done as this. What I said is: currently there are concurrent enhancements and releases. So, between the 1st RC and the final release there can be a lot of differences, witch is not --from my point of view-- a good thing. IIRC, the 1.1 vote was for the 1.1RC1, not for the 1.1 branch witch doesn't exist. But I agree with you: it a such branch 1.1 should exist ;-) 2012/7/2 mehdi houshmand med1...@gmail.com: Excuse my ignorance here, but why do any changes to trunk affect 1.1RC*? The 1.1 branch has already been defined and voted upon, I don't see how any changes to trunk would affect it? I'm not very familiar with the FOPs releasing process so do excuse me. Mehdi On 2 July 2012 13:42, Pascal Sancho psancho@gmail.com wrote: Mehdi, I speak about post 1.1RC1. Your merge will be against the trunk. What about the 1.1RC2 or 1.1 final? In the current usage, *all* FOP releases are tagged directly from trunk (via a branch that is only to set FOP version and lib dependencies). So, every further RC or final releases are planed to be ma 2012/7/2 mehdi houshmand med1...@gmail.com: Hi Pascal, I won't be merging this into anything other than trunk. Sorry, maybe I should have made that more explicit. Mehdi On 2 July 2012 12:32, Pascal Sancho psancho@gmail.com wrote: Hi, +1 for merging it to trunk. That said, I'm a little puzzled with the release process. In my mind, a RC should come before a production release, freezing all features. Only bugfix should be permitted on RC. Adding new feature to RC2 is a precedent that allows to add a new feature after each RC, witch need to release a new... RC, etc. I humbly suggest that the release process start with a 1.1 branch, from witch RCx and final release will be tagged, that should allow to continue merging branches onto trunk without any interaction on branch release. WDYT? 2012/7/2 Chris Bowditch bowditch_ch...@hotmail.com: On 26/06/2012 15:39, mehdi houshmand wrote: Sorry, added [VOTE] to subject line... My bad +1 from me. Good work Mehdi and Pete. Chris On 26 June 2012 15:38, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: Hi All, I think we've got to the stage in the URI unification branch where it's ready to be merged into trunk (not into 1.1RC1). I know there have been proponents against the inclusion of this feature and/or those who are concerned the wider implications as it means FOP has fewer contingency methods when attempting file access. I'll try and explain how we've addressed those concerns as well as some of the code improvements we've made. - Syntactic URI fall-back mechanisms - if a URI is syntactically erroneous i.e. contains white-space, \ instead of /, we do some validation on to mitigate some of the common mistakes. However, we don't allow for falling back to 'new File(.)' or new URL(...).openStream() since these can obviously cause clashes in a highly parallelised multi-tenant environment. - Single FOP conf parse - Previously the renderer specific regions of the FOP conf was being parsed on every run. This is costly to performance for the obvious reason, but as well as this, it meant that font auto-detection was having to be executed on every run. The font-caching was created to mitigate some of those performance costs, however, caching the FOP conf makes much more sense. It means we can get rid of the font-caching and don't have to to worry about performance but it also allowed to do a lot of clean up in the configuration packages. The renderer specific config is also lazy loaded such that it is only parsed when the respective renderer is invoked, mitigating the one-off cost of parsing that config. - The environment profile - We've created an environment profile that abstracts the system in which FOP is invoked. This allows us to programmatically enforce restrictions to, for example, font-caching and auto-detection since users may want to control this behaviour for any number of reasons. - Improved URI
Re: [VOTE] Merge Temp_URI_Unification
Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the branch imminently and update the docs as appropriate On 2 July 2012 14:40, Glenn Adams gl...@skynav.com wrote: On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@gmail.com wrote: Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little there ;) Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this burdens you in some way, could you let me know how and maybe we can come to some resolution? As far as I can see, it shouldn't affect the 1.1rc1 branch at all. Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then create a fop_1.1rc1 tag on that branch that corresponds with the current rc1 rev.
Re: [VOTE] Merge Temp_URI_Unification
? You missed something; this is the default implementation. This is pretty much only for the CLI use-case, if users wish to define their own implementation, all they have to do is implement the interface. • in DefaultTempResourceResolver.getTempFile: the File.createTempFile method should be used instead of querying the ‘java.io.tmpdir’ property. Done. src/java/org/apache/fop/fonts/FontConfig.java • all this interface declares is an inner FontConfigParser interface. Why not simply promote FontConfigParser as a top-level interface and remove FontConfig? The intention was to provide an interface that covers both use cases, AFP and everything else, so that we could make the font configuration process a bit more OOP and a bit less if (something) do something. Time constraints howerver... src/java/org/apache/fop/fonts/FontConfigurator.java • some documentation about the T generic parameter would be good. Also, shouldn’t this parameter be bounded by some interface? See the reply above. Again, there's a TODO suggesting just that, again, time constraints... Thanks, Vincent On 03/07/12 10:35, mehdi houshmand wrote: Thanks guys, that's 5 x +1 and no one in opposition. I'll merge in the branch imminently and update the docs as appropriate On 2 July 2012 14:40, Glenn Adams gl...@skynav.com wrote: On Mon, Jul 2, 2012 at 7:25 AM, mehdi houshmand med1...@gmail.com wrote: Ahh I see, ok, thanks Pascal. I think we got our wires crossed a little there ;) Glenn, my plan was to merge the URI-resolution stuff in tomorrow. If this burdens you in some way, could you let me know how and maybe we can come to some resolution? As far as I can see, it shouldn't affect the 1.1rc1 branch at all. Go ahead. I'm going to rename the fop_1.1rc1 branch to fop_1.1 and then create a fop_1.1rc1 tag on that branch that corresponds with the current rc1 rev.
Re: [VOTE] Merge Temp_URI_Unification
Just a few amendments:
- File.createTempFile(...) failed the unit tests and I didn't have time to
investigate why, this could be done in the future, though I'm not sure the
pros/cons of doing so.
- The method signature change getBaseURI - getBaseDirectoryURI wasn't
done. After speaking to PH, it didn't seem appropriate to refer to it as a
directory since it could be anything. The javadoc clearly describes the
behaviour of the method, I think this is sufficient for now.
On 4 July 2012 08:38, mehdi houshmand med1...@gmail.com wrote:
On 3 July 2012 15:48, Vincent Hennebert vhenneb...@gmail.com wrote:
I had started to build up a list of questions and comments but didn’t
get round to finishing it in time. Anyway, here it is, hopefully it will
still provide valuable feedback. The most important items to address are
the possible regression regarding strict FO validation and the public
API.
The new classes FopConfParser, FopFactoryBuilder and FopFactoryConfig
should be renamed into FOPConfParser, FOPFactoryBuilder and
FOPFactoryConfig. The fact that some existing public classes have Fop in
lower case in their names was a mistake that was discovered after the
API was frozen. Let’s not do that mistake again.
I don't agree, I think this makes the classes more inconsistent rather
than less so. I don't particularly have an opinion whether they should be
Fop* or FOP* but I think either way, there should be consistency
There are quite a few typos in the javadocs of the new class, it would
be good to fix them.
src/java/org/apache/fop/apps/EnvironmentProfile.java
• class javadoc: “The environment profile represents the restrictions
and allowances that FOP is”... what?
Done.
src/java/org/apache/fop/apps/EnvironmentalProfileFactory.java
• should be renamed into EnvironmentProfileFactory
• in the inner Profile class: there are checks that constructor
parameters are not null, except for FontManager. So may that be null
then? Doesn’t look like.
Done.
src/java/org/apache/fop/apps/FOUserAgent.java
• left-over TODO in resolveURI: should that be left as-is for now?
Yes. There are XGC classes that require this, there's already a TODO there
suggesting that we intend on removing this.
• getRendererConfig(String mimeType, RendererConfigParser configCreator)
isn’t there a risk of mismatch between the given mimeType and
configCreator? Can’t the mimeType be taken from the
RendererConfigParser.getMimeType method?
No. The same parser can be used for more than one MIME type and we don't
want the config data to be retrieved from the wrong MIME type.
• getRendererConfiguration(String mimeType)
This comment:
// silently pass over configurations without mime type
Really? Don’t we want to at least display a warning?
This code is copy/pasted from elsewhere, we could have fixed this, but
we'd also have to test it. Time constraints didn't allow such luxuries.
• public ColorSpaceCache getColorSpaceCache() {
/** TODO: javadoc*/
Done
• getHyphPatNames()
this is hard to pronounce; also ‘Pat’ can easily be mistaken for
‘Path’
s/getHyphPatNames/getHyphenationPatternNames/?
Luckily it's written so you don't have to pronounce it ;). No seriously,
done.
src/java/org/apache/fop/apps/FopConfParser.java
• there’s a mistake in the handling of ‘strict-validation’: this is
related to checking the conformance of XSL-FO documents against the
spec. The setting to strictly check the validity of config files is
‘strict-configuration’
Again, there's a TODO, I don't think this is a regression but just
something that was confused previously, though again, time constraints...
src/java/org/apache/fop/apps/FopFactoryBuilder.java
• the buildConfig method is deprecated but is used by the build method
underneath, which is itself not deprecated. But then it shouldn’t rely
on a deprecated method?
The javadoc makes it clear that the only reason this is there is to
maintain backwards compatibility, we'll remove it at some point in the
future when users are more comfortable with the new API design.
src/java/org/apache/fop/apps/FopFactoryConfig.java
• This is an interface whose methods’ javadocs refer to the FopFactory
concrete class. So an abstraction depends on a concrete
implementation. Surely that should be the other way around?
Again, this is to make the transition easier for users. Users are used to
accessing these members via the FopFactory and the javadocs help lubricate
the transition.
src/java/org/apache/fop/apps/io/InternalResourceResolver
• what does ‘Internal’ stand for?
Stand for? It doesn't stand for anything. This class is FOPs internal
resource resolver that does some primitive URI validation when strings are
given and holds the base URI when relative URIs are given.
• getBaseURI: I don’t think adding a slash at the end of the URI if it’s
not there is desirable, because
Re: [VOTE] Merge Temp_URI_Unification
On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com wrote:
One thing I forgot to mention: this work deserves its entry in the
status.xml file, with importance set to ‘high’.
snip/
Let me insist on that one. The inconsistency is actually introduced by
Fop classes. Before the merge there were 14 classes having FOP in their
names, vs 6 having Fop. Also, the product name is FOP, not Fop, and that
should be reflected in the class names.
I still don't agree, it's not about the number of classes but rather the
importance and location of those classes; FopFactory.java, Fop.java. If you
feel very strongly about it, feel free to change it, I won't oppose it, but
when someone thinks wtf!!! Why are there so many different ways to write
FOP!?!?! and they do an svn blame, I don't want my name anywhere near it.
snip/
I’m confused. It seems that I can call that method with an
‘application/pdf’ mimeType and a PSRendererConfigParser instance. In
which case the parser would not be able to parse PDF-specific options,
and would silently ignore them. Or did I miss something?
You missed something. For most the configurators, you are correct, but for
the Bitmap configurators it gets a little bit more involved, they re-use
the same code. It was a choice between either a) duplicating code, or b)
doing what we did. (There was a c) option, but as always, it involved a lot
more redesign than we had time for.)
snip/
There does seem to be a regression. Before, the FopFactoryConfigurator
object was getting the strict-validation element from the config file
and calling FopFactory.setStrictValidation if it was set to true. This
is no longer the case.
I’ve just tried to render a table with table-footer after table-body,
and now a validation error is thrown even if I have strict-validation
set to false in my config file. No validation error was thrown before.
I've fixed the underlying issue but this is an interesting one; it isn't
obvious that settings from the fop conf override the settings from the
command line options. (Pete probably wrote this part hahaha ;) )
So when you remove it you will have to re-write the build method such
that it doesn’t call buildConfig anymore. How will you do? (Admittedly
I haven’t studied the new API in much detail.)
And BTW, what is the recommended way to get a FopFactoryConfig? The
javadoc of buildConfig doesn’t say. I think it should.
The client doesn't need access to the FopFactoryConfig object, it's a
wrapper for all the configuration objects that FOP uses. You instantiate a
FopFactory by using the FopFactoryBuilder.build(). I was going to write up
documentation suggesting as much, but I haven't had the chance to do so yet.
I’m not sure I understand. How is that supposed to help? Wouldn’t it
actually be more helpful if the FopFactory were now referring to the
interface? That would indicate to users that something is going to
change and they should take the habit of looking at FopFactoryConfig
from now on.
I think the thought process was that users would be more used to accessing
those members via the FopFactory so linking back to that same object would
be more explicit. Maybe it doesn't make sense to anyone other than me/Pete.
src/java/org/apache/fop/apps/io/InternalResourceResolver
Why is it a public class then if it’s supposed to be internal to FOP?
IIC that apps/io package is meant to become part of the public API?
Well Java doesn't have a project only access modifier so... Where else
would we put it? This class is peculates through FOP so it has to be public.
• getBaseURI: I don’t think adding a slash at the end of the URI if
it’s
not there is desirable, because that effectively changes the base URI.
That may lead to very confusing errors.
As the javadoc suggests this is for giving you a directory base URI, I've
changed the method signature to {getBaseURI, getBaseDirectoryURI}.
Ah, I’m glad to hear that I was right to assume that the getBaseURI
method returns a base URI :-)
What I’m talking about is that, by adding a final ‘/’ to the given
string, you are effectively changing the base URI.
For example, that method is called by the AFPResourceAccessor class,
which passes as a parameter the baseURI it’s been given, which that
getBaseURI method may change into a different base URI! This is very
misleading and may result into hard-to-find errors.
The behaviour is the same as it was previously. I wanted to have a single
base URI for ALL of FOPs URI resolution, but that would be devastating to
backwards compatibility. Don't hate the player, hate the game ;)
src/java/org/apache/fop/apps/io/TempResourceResolver
You missed something; this is the default implementation. This is pretty
much only for the CLI use-case, if users wish to define their own
implementation, all they have to do is implement the interface.
OK, so presuming I want to write my own implementation that does a more
fine-grained
Re: [VOTE] Merge Temp_URI_Unification
I wouldn't worry Clay, I'm not sure I really know what this thread is about any more either. Either way, it's been merged but thanks for your support. The fix of this regression is easy, I'll fix it in the morning. On 4 July 2012 18:32, The Web Maestro the.webmaes...@gmail.com wrote: I'm a bit confused... Am I correct that this [VOTE] relates to merging the Temp_URI_Unification to fop/trunk and not to FOP-1.1rc*? If so, then +1 and if not then +0 since I don't quite understand... (not blocker, but not enough info for me to +1... ;-) Kind regards, Clay Leeds -- the.webmaes...@gmail.com - http://ourlil.com/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet On Wed, Jul 4, 2012 at 9:26 AM, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 04/07/2012 17:15, Glenn Adams wrote: On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.com mailto:med1...@gmail.com wrote: On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com mailto:vhenneb...@gmail.com wrote: There does seem to be a regression. Before, the FopFactoryConfigurator object was getting the strict-validation element from the config file and calling FopFactory.setStrictValidation if it was set to true. This is no longer the case. I’ve just tried to render a table with table-footer after table-body, and now a validation error is thrown even if I have strict-validation set to false in my config file. No validation error was thrown before. I've fixed the underlying issue but this is an interesting one; it isn't obvious that settings from the fop conf override the settings from the command line options. (Pete probably wrote this part hahaha ;) ) They shouldn't. Command line options should override the conf file. Agreed, but IIUC, the team just copied the existing functionality due to time constraints. We should probably log a bug to track that as an issue. Thanks, Chris
Re: [VOTE] Merge Temp_URI_Unification
Hi Chris/Glenn/Anyone else, You say command-line options should override the fop.xconf values, which makes sense. But should not-given command-line options override fop.xconf values too? Bare with me here, there is sense in the folly of that sentence. Ok, so let's take the example above, with strict FO validation, from the command line you have two options: 1) fop -r ... other args or 2) fop ... other args Obviously in option 1, you'd want strict FO validation to be invoked, regardless of what's in the fop conf. But how do we treat option 2? We're not explicitly telling it NOT to validate strictly, so how would a user expect FOP to behave? On 4 July 2012 17:26, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 04/07/2012 17:15, Glenn Adams wrote: On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand med1...@gmail.commailto: med1...@gmail.com wrote: On 4 July 2012 12:32, Vincent Hennebert vhenneb...@gmail.com mailto:vhenneb...@gmail.com wrote: There does seem to be a regression. Before, the FopFactoryConfigurator object was getting the strict-validation element from the config file and calling FopFactory.setStrictValidation if it was set to true. This is no longer the case. I’ve just tried to render a table with table-footer after table-body, and now a validation error is thrown even if I have strict-validation set to false in my config file. No validation error was thrown before. I've fixed the underlying issue but this is an interesting one; it isn't obvious that settings from the fop conf override the settings from the command line options. (Pete probably wrote this part hahaha ;) ) They shouldn't. Command line options should override the conf file. Agreed, but IIUC, the team just copied the existing functionality due to time constraints. We should probably log a bug to track that as an issue. Thanks, Chris
Re: [VOTE] Merge Temp_URI_Unification
Ok, so I've made the CLI options override when set, and not override when not set. I think that CommandLineOption class needs a little TLC, we can use Commons CLI or some such library ( http://java-source.net/open-source/command-line). No point reinventing the wheel. On 5 July 2012 08:27, Glenn Adams gl...@skynav.com wrote: On Thu, Jul 5, 2012 at 12:41 AM, mehdi houshmand med1...@gmail.comwrote: Hi Chris/Glenn/Anyone else, You say command-line options should override the fop.xconf values, which makes sense. But should not-given command-line options override fop.xconf values too? Bare with me here, there is sense in the folly of that sentence. Ok, so let's take the example above, with strict FO validation, from the command line you have two options: 1) fop -r ... other args or 2) fop ... other args Obviously in option 1, you'd want strict FO validation to be invoked, regardless of what's in the fop conf. But how do we treat option 2? We're not explicitly telling it NOT to validate strictly, so how would a user expect FOP to behave? In the case of strict validation, if either configuration file or command line option says do strict validation, then strict validation should apply. We would need an option don't do strict validation in order to allow the command line to override a configuration file saying to perform strict validation.
Re: svn commit: r1362823 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/render/pcl/PCLGraphics2D.java status.xml
I did create a bugzilla entry (
https://issues.apache.org/bugzilla/show_bug.cgi?id=53563), I just didn't
put the bug number in the commit message, my apologies, I was complacent in
that regard. Is it worth changing the commit message retrospectively to add
the bugzilla entry?
Mehdi
On 18 July 2012 11:06, Chris Bowditch bowditch_ch...@hotmail.com wrote:
On 18/07/2012 10:12, me...@apache.org wrote:
Hi Mehdi,
I thought we agreed all code changes should have a Bugzilla entry opened
for them? Can you create one retrospectively?
Thanks,
Chris
Author: mehdi
Date: Wed Jul 18 09:12:10 2012
New Revision: 1362823
URL:
http://svn.apache.org/viewvc?**rev=1362823view=revhttp://svn.apache.org/viewvc?rev=1362823view=rev
Log:
Removed a method call that could cause a java.awt.HeadlessException in
PCLGraphics2D (brought it inline with PDF/PS/AFP-Graphics2D classes)
Modified:
xmlgraphics/fop/trunk/src/**java/org/apache/fop/render/**
pcl/PCLGraphics2D.java
xmlgraphics/fop/trunk/status.**xml
Modified: xmlgraphics/fop/trunk/src/**java/org/apache/fop/render/**
pcl/PCLGraphics2D.java
URL: http://svn.apache.org/viewvc/**xmlgraphics/fop/trunk/src/**
java/org/apache/fop/render/**pcl/PCLGraphics2D.java?rev=**
1362823r1=1362822r2=1362823**view=diffhttp://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java?rev=1362823r1=1362822r2=1362823view=diff
==**==**
==
---
xmlgraphics/fop/trunk/src/**java/org/apache/fop/render/**pcl/PCLGraphics2D.java
(original)
+++
xmlgraphics/fop/trunk/src/**java/org/apache/fop/render/**pcl/PCLGraphics2D.java
Wed Jul 18 09:12:10 2012
@@ -25,7 +25,6 @@ import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.**GraphicsConfiguration;
-import java.awt.GraphicsEnvironment;
import java.awt.Image;
import java.awt.Paint;
import java.awt.Shape;
@@ -44,6 +43,7 @@ import java.text.**AttributedCharacterIter
import org.apache.xmlgraphics.java2d.**AbstractGraphics2D;
import org.apache.xmlgraphics.java2d.**GraphicContext;
+import org.apache.xmlgraphics.java2d.**GraphicsConfigurationWithTrans**
parency;
import org.apache.xmlgraphics.util.**UnitConv;
/**
@@ -127,8 +127,7 @@ public class PCLGraphics2D extends Abstr
/** {@inheritDoc} */
public GraphicsConfiguration getDeviceConfiguration() {
-return GraphicsEnvironment.**getLocalGraphicsEnvironment()
-.getDefaultScreenDevice().**getDefaultConfiguration();
+return new GraphicsConfigurationWithTrans**parency();
}
/**
Modified: xmlgraphics/fop/trunk/status.**xml
URL: http://svn.apache.org/viewvc/**xmlgraphics/fop/trunk/status.**
xml?rev=1362823r1=1362822r2=**1362823view=diffhttp://svn.apache.org/viewvc/xmlgraphics/fop/trunk/status.xml?rev=1362823r1=1362822r2=1362823view=diff
==**==**
==
--- xmlgraphics/fop/trunk/status.**xml (original)
+++ xmlgraphics/fop/trunk/status.**xml Wed Jul 18 09:12:10 2012
@@ -63,6 +63,10 @@
documents. Example: the fix of marks layering will be such a case
when it's done.
--
release version=FOP Trunk date=TBD
+ action context=Renderers dev=MH type=add fixes-bug=53563
importance=low
+Removed a method call to the java.awt.GraphicsEnvironment.**
getLocalGraphicsEnvironment().**getDefaultScreenDevice()
+that could (in a headless environment) throw a
java.awt.HeadlessException
+ /action
action context=Renderers dev=VH type=add importance=high
When PDF accessibility is enabled, treat repeated table
headings as artifacts. This allows
screen readers to read the header only once at the beginning of
the table and the footer
--**--**-
To unsubscribe, e-mail:
fop-commits-unsubscribe@**xmlgraphics.apache.orgfop-commits-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.**
apache.org fop-commits-h...@xmlgraphics.apache.org
Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
As we've seen this morning, my ineptitude at even basic bureaucracy doesn't really qualify me to show a bias to either side, but I'll give my 2 cents worth since I am a stakeholder in this debate: On 18 July 2012 13:17, Vincent Hennebert vhenneb...@gmail.com wrote: snip/ Well, the problem is probably not the lack of a BTS here, it’s probably the commit message that shouldn’t be that short. And a longer description should be in status.xml anyway. Also, I find the list of comments that usually appears in Bugzilla entries confusing more than anything else. You have to wander through the comments to understand what is going on. Surely having lots of comments is a good thing? It means there's been a discussion about the issue and possibly some conclusion has been come to as to how to solve the problem. Even if the comments don't arrive at a conclusion, then surely having the discussion would better document nuances surrounding any particular issue? The only time this can become confusing is if there are disparities in the flow of the conversation between bugzilla comments and mailing list posts. This doesn't happen very often so I don't really see this as a consideration we should be trying to mitigate. That said, if a bug affects the rendering part of FOP which is not really unit-testable at the moment, the commit is unlikely to contain any test, so it helps to be able to retrieve an example output on Bugzilla. And I suppose that for the sake of consistency, the same should be done for layout bugs. Agreed! I think whatever we decide, we must be consistent if only to prevent confusion. It's easier following one rule for all than it is remember and adhering to caveats. Since everyone seems to be in favour of switching to Bugzilla, I suppose I’ll start from now on. But I urge the proponents of this move to convert the status.xml logic as soon as possible. Again I agree with Vincent here, that status.xml gets me every time! I almost invariably forget to update it, now again, that's my bad but it does seem somewhat redundant if all that information is in bugzilla/JIRA. I appreciate it's used for release info, but there's got to be a better solution. I'm happy to follow the consensus on this one and I'm glad we've come to an agreement. Mehdi
Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
I know this isn't directly relevant to this tread, but something else to consider while we're on the subject of JIRA and bug tracking is integration between SVN and JIRA itself. Having worked a little bit with PDFBox, they seem to have quite tight integration between the two such that (I think) JIRA prefixes SVN commits automatically with JIRA IDs (the JIRA number.) I don't know if this integration comes out the box or whether we need to do something to get it working, but it seems like a good idea. Also, I know Jeremias is a PDFBox committer and this applies to anyone else familiar with these tools, if they could chime in and give us some suggestions as to either useful tools and/or process best-practices. I should confess (as has probably been made abundantly obvious from silly mistakes) I despise SVN and eagerly anticipate the inevitable migration to a DSCVS of some type (preferably but not exclusively Git.) I appreciate this may seem like putting the cart before the horse since we don't really know time-lines for JIRA migration, but it's better to get this out in the open and iron out these process/workflow protocols well before we migrate. Maybe we should start a new thread for this? We seem to be hijacking a commit message... Mehdi On 19 July 2012 09:14, Chris Bowditch bowditch_ch...@hotmail.com wrote: On 18/07/2012 14:06, mehdi houshmand wrote: Hi Mehdi, As we've seen this morning, my ineptitude at even basic bureaucracy doesn't really qualify me to show a bias to either side, but I'll give my 2 cents worth since I am a stakeholder in this debate: On 18 July 2012 13:17, Vincent Hennebert vhenneb...@gmail.com mailto: vhenneb...@gmail.com wrote: snip/ Well, the problem is probably not the lack of a BTS here, it’s probably the commit message that shouldn’t be that short. And a longer description should be in status.xml anyway. Also, I find the list of comments that usually appears in Bugzilla entries confusing more than anything else. You have to wander through the comments to understand what is going on. Surely having lots of comments is a good thing? It means there's been a discussion about the issue and possibly some conclusion has been come to as to how to solve the problem. Even if the comments don't arrive at a conclusion, then surely having the discussion would better document nuances surrounding any particular issue? +1. I totally agree and that's one of the key benefits of using BTS over status.xml. The only time this can become confusing is if there are disparities in the flow of the conversation between bugzilla comments and mailing list posts. This doesn't happen very often so I don't really see this as a consideration we should be trying to mitigate. Yes I agree that is the exception rather than the rule. That said, if a bug affects the rendering part of FOP which is not really unit-testable at the moment, the commit is unlikely to contain any test, so it helps to be able to retrieve an example output on Bugzilla. And I suppose that for the sake of consistency, the same should be done for layout bugs. Agreed! I think whatever we decide, we must be consistent if only to prevent confusion. It's easier following one rule for all than it is remember and adhering to caveats. Since everyone seems to be in favour of switching to Bugzilla, I suppose I’ll start from now on. But I urge the proponents of this move to convert the status.xml logic as soon as possible. Again I agree with Vincent here, that status.xml gets me every time! I almost invariably forget to update it, now again, that's my bad but it does seem somewhat redundant if all that information is in bugzilla/JIRA. I appreciate it's used for release info, but there's got to be a better solution. I'm happy to follow the consensus on this one and I'm glad we've come to an agreement. Yes I think we have consenus. I can start a formal vote if necessary, but I don't think it is in this instance. Thanks, Chris Mehdi
Re: SVN/Jira integration was: [Re: svn commit: r1360665 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/ test/java/org/apache/fop/intermediate/ test/java/org/apache/fop/layoutengine/
Hi Alex, Thanks for the response, that's been very informative, I think if we considered SVN/Jenkins integration, it'd make life a lot easier. The more we can automate, the fewer the mistakes, that's pretty much my only reasoning, though obviously it'd have to be investigated to come up with a workflow proposal that everyone agrees with. As for Jenkins/Git, I absolutely agree, we're users of both and I'm a staunch advocate of both too. Jenkins has its little quirks (I was going to say, I wish you could create job templates, but turns out you can [1]) but works like a dream most the time. And Git, well, I kinda like think Git is to SVN as Linux is to Windows, both get the job done, but once you get to appreciate what Git does, it just makes life so much easier. While we're on the subject, if we could use a github (or similar, though I don't know any other) system where version control, issue/bug tracking, wikis and forks were all under one roof... Anyways, enough with my pipe dreams. Thanks again, Mehdi [1] http://blog.cloudbees.com/2012/02/using-jenkins-templates-plugin-to.html On 19 July 2012 17:09, Alexios Giotis alex.gio...@gmail.com wrote: Hi Mehdi, I will continue the hijacking of the commit message . I feel that opening a new thread might be disturbing and I don't know if the FOP community is interested. I hope I am helping a little to improve the processes and not spamming your inbox. I am not familiar with the Apache infrastructure but some years ago I updated our own development infrastructure (SVN / Jira / Jenkins / Artifactory / Confluence / ...) and are currently migrating from svn to git. On Jul 19, 2012, at 11:39 AM, mehdi houshmand wrote: Having worked a little bit with PDFBox, they seem to have quite tight integration between the two such that (I think) JIRA prefixes SVN commits automatically with JIRA IDs (the JIRA number.) I don't know if this integration comes out the box or whether we need to do something to get it working, but it seems like a good idea. Actually JIRA has no write access to SVN and is not changing commit messages or anything. By looking at SVN [1] and Jira [2], I can tell that PDFBox committers are simply following the good practice of prefixing most commits with the related Jira issue. I guess that this is now going to be followed by FOP committers too. Although all SVN/Jira integration methods search the whole commit message for something looking like a Jira issue number, I suggest that you agree on a pattern. Two commonly used patterns for commit messages are: FOP-1: Commit message [FOP-1] Commit message We follow the 2nd as we may easily spot it, it is used by other tools (e.g. maven release plugin) and it's easier to track it with an SVN post commit hook that may reject the commit, send notification emails etc. [1] http://svn.apache.org/repos/asf/pdfbox/trunk [2] https://issues.apache.org/jira/browse/PDFBOX Related to the SVN / Jira integration, all the methods that I know, require someone with admin access to the infrastructure, and they are: ** A plugin installed to Jira. It adds an additional tab that shows the commits related to the Jira issue, see [3]. ** Attlassian FishEye [4]. The Apache Camel project is somehow using it, for example scroll a little down and click the Source tab in [5]. Looks good but it seams that Attlassian is hosting the service. ** A plugin [6] installed in Jenkins (continuous integration tool) that adds a comment in Jira with the revision and the changed files when a new build has been created. Strangely [6] is currently showing a random plugin page each time refresh the page. If this is happening while you are reading this, use a google cached page. I selected and deployed the plugin for Jenkins because when the comment appears, the reporter of the issue knows that she could get and test an updated snapshot version of that project. The Apache infrastructure hosts Jenkins at [7]. I am a very happy Jenkins (Hudson) user and I recommend it. It should be very easy for everyone to set up a FOP build (needs SVN location, ant target and a selection of some options). [3] https://studio.plugins.atlassian.com/wiki/display/SVN/Subversion+JIRA+plugin [4] http://www.atlassian.com/software/fisheye/overview [5] https://issues.apache.org/jira/browse/CAMEL-4954 [6] https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin [7] https://builds.apache.org/ Also, I know Jeremias is a PDFBox committer and this applies to anyone else familiar with these tools, if they could chime in and give us some suggestions as to either useful tools and/or process best-practices. I should confess (as has probably been made abundantly obvious from silly mistakes) I despise SVN and eagerly anticipate the inevitable migration to a DSCVS of some type (preferably but not exclusively Git.) I have been using git for over a year and have decided to switch most projects to git
Re: svn commit: r1364567 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fonts/ layoutmgr/inline/ pdf/ render/ render/intermediate/ render/ps/ util/
Glenn,
Is it worth porting these javadoc amendments to the 1.1 branch? I don't
mind doing it if you'd like them in 1.1.
Mehdi
On 23 July 2012 11:21, me...@apache.org wrote:
Author: mehdi
Date: Mon Jul 23 10:21:23 2012
New Revision: 1364567
URL: http://svn.apache.org/viewvc?rev=1364567view=rev
Log:
Fixed all javadoc issues, ant javadocs now works without errors
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontCache.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontManager.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AbstractPageNumberCitationLayoutManager.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/StreamCacheFactory.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractRendererMaker.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/intermediate/IFDocumentHandlerConfigurator.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/render/ps/PSRendererOption.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/util/ColorSpaceCache.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java?rev=1364567r1=1364566r2=1364567view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/DefaultFontConfigurator.java
Mon Jul 23 10:21:23 2012
@@ -52,7 +52,6 @@ public class DefaultFontConfigurator imp
/**
* Main constructor
- * @param fontInfoConfig the configuration object
* @param fontManager the font manager
* @param listener the font event listener
* @param strict true if an Exception should be thrown if an error is
found.
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontCache.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontCache.java?rev=1364567r1=1364566r2=1364567view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontCache.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontCache.java Mon
Jul 23 10:21:23 2012
@@ -462,10 +462,9 @@ public final class FontCache implements
}
/**
- * Retrieve the last modified date/time of a URL.
+ * Retrieve the last modified date/time of a URI.
*
- * @param url
- *the URL
+ * @param uri the URI
* @return the last modified date/time
*/
public static long getLastModified(URI uri) {
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontManager.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontManager.java?rev=1364567r1=1364566r2=1364567view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontManager.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontManager.java
Mon Jul 23 10:21:23 2012
@@ -138,7 +138,6 @@ public class FontManager {
/**
* Whether or not to cache results of font triplet
detection/auto-config
- * @param useCache use cache or not
*/
public void disableFontCache() {
fontCacheManager = FontCacheManagerFactory.createDisabled();
@@ -163,8 +162,7 @@ public class FontManager {
/**
* Deletes the current FontCache file
- * @return Returns true if the font cache file was successfully
deleted.
- * @throws FOPException -
+ * @throws FOPException if an error was thrown while deleting the
cache
*/
public void deleteCache() throws FOPException {
fontCacheManager.delete(getCacheFile(true));
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AbstractPageNumberCitationLayoutManager.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AbstractPageNumberCitationLayoutManager.java?rev=1364567r1=1364566r2=1364567view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AbstractPageNumberCitationLayoutManager.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/layoutmgr/inline/AbstractPageNumberCitationLayoutManager.java
Mon Jul 23 10:21:23 2012
@@ -136,7 +136,7 @@ public abstract class AbstractPageNumber
/**
* @return {@link
org.apache.fop.area.inline.UnresolvedPageNumber#FIRST} or
- * {@linkorg.apache.fop.area.inline.UnresolvedPageNumber#LAST}
+ * {@link
Re: URIs: scheme vs. schema
Hi Jeremias, You are correct, I'll fix this as soon as it's convenient. Mehdi On 26 July 2012 17:36, Jeremias Maerki d...@jeremias-maerki.ch wrote: When I've looked through the changes made to FOP's public API, I was wondering what a SchemaAwareResourceResolver was. First thought was: what does that have to do with XML Schema? With the recent thread on fop-users I realized that this should really be SchemeAware. Please check the naming in java.net.URI. BTW, can I hope for a convenience adapter for the URIResolver interface at some point, or do I have to write that myself eventually? I'm dreading the day where I have to adjust all my applications to the API changes. From what I've seen so far, I can't count a single change that I'd consider to be an improvement, only steps backwards, compared to before the changes. I'm only seeing lots of work adjusting to the changes. Jeremias Maerki
Ça va? Guava
Hi All, I've come across a yet another concurrency based bug in FOP, this time to do with how we handle AFP character-sets. The problem in this scenario is that the CharacterSetBuilders are singletons and their creation wasn't really intended to be used in a heavily multithreaded system. As such, we don't really have a good implementation of a thread-safe cache for caching expensive-to-create objects. That's the problem I'm looking to solve, and the solution? Guava. The Guava libraries [1] (under Apache 2.0 license) have well tested, intuitive classes that do a lot of the low-level mechanisms that we often need, and there's really no point in reinventing the wheel. The obvious cost of adding this library is the addition of a JAR in the class-path, as such I'm not calling for a vote at this point, I just wanted to know what the general consensus on this was. The Guava library is often heralded as the new Apache Commons and praised for being well maintained [2][3] but I'd suggest if anyone is sceptical of the benefits, to do some research. I accept, however, that developers can get a religious zeal about these kind of things, I'm not suggesting Guava is the cure to world poverty, just that it could help handle some of the lower-level tools. Though I'd love to spend time implementing fit-for-purpose mechanisms, these issues are usually bugs that our clients want fixed NOW!!! And so we find ourselves constantly saying ok, we'll do it this way for now, but next time we'll find a proper fix... This is a subject I've been wanting to bring up for a while, we've had to implement several thread-safe caching systems (for example in the pdf-image-plugin) but I wanted to wait for compelling reason. Though the reason above isn't any more compelling than for the pdf-image-plugin, I think the addition of this library would prevent some of the low-level mistakes that we all make sometimes. If anyone has questions, I'd be happy to explain my motivations in further detail. Mehdi [1] http://code.google.com/p/guava-libraries/ [2] http://stackoverflow.com/questions/137/apache-commons-vs-guava-formerly-google-collections [3] http://stackoverflow.com/questions/4542550/what-are-the-big-improvements-between-guava-and-apache-equivalent-libraries
Re: Ça va? Guava
Hi Alex/All, Firstly I should note that no, I'm not talking about a single case, in fact I've already fixed bz#53685 I just haven't pushed it up yet (or committed it in svn speak.) Anyways, this particular issue doesn't warrant a ripping apart of anything, it's simply a case of caching using a non-unique key. In fact, I'm somewhat curious if it's even a mistake, if its intended use is to cache charactersets/codepages and use them across multiple docs... I digress. I wasn't suggesting that we use Guava immediately, I was just opening the subject up for discussion. I tend to shy from sprinkling synchronized blocks and locks willy nilly at concurrency problems, obviously sometimes it's the only course of action, but there are also costs. There can be mistakes made on what object you actually lock on, which may not be easy to find; there can also be a performance impact when synchronising when another course of action would be better performant. I'm also not suggesting that we go in and replace ALL caches with Guava caches or any thing that over-zealous, I just wanted to know if, next time I have to write some sort of cache and the Guava one's fit the bill, if anyone would mind me using them? I'll reiterate, this isn't a religious argument at all, if the solution is just to use a concurrent collection, that's what I'll use, but if a more involved implementation is needed, I don't believe in reinventing the wheel. You are right however, if we introduced such a library, ideally we'd go round replacing redundant code. However, that's not really how it works in practicality. If it were introduced, we'd introduce the appropriate Guava constructs iteratively, for example, looking at the code around this bug I can see there may be performance implications in several places and a possible concurrency issue. These may (or may not) be solvable using Guava, but I'd like to have the option to look in the libraries for tried and well tested solutions. Thanks Mehdi On 9 August 2012 21:07, Alexios Giotis alex.gio...@gmail.com wrote: Hi Mehdi, Guava is a really nice library, but what exactly is the issue(s) you would like to address with it ? Any stack traces ? If you refer to the recently opened bz #53685, then this seems like a problematic selection of the cache key and not a concurrency problem. I don't think Guava would help there. If the creation of CharacterSetBuilders is not thread safe, why don't you just protect it with a synchronised block or a Lock ? java.util.concurrent was a quite powerful addition in Java 5. In general, I would justify adding a runtime dependency whose size is comparable to FOP's size, if there are issues that can't be resolved equally well by writing a few lines of code. Or, if you intend to refactor FOP's internal data structures and Guava would help to reduce the amount of code, the number of bugs and increase readability. Alex Giotis On Aug 9, 2012, at 11:59 AM, mehdi houshmand med1...@gmail.com wrote: Hi All, I've come across a yet another concurrency based bug in FOP, this time to do with how we handle AFP character-sets. The problem in this scenario is that the CharacterSetBuilders are singletons and their creation wasn't really intended to be used in a heavily multithreaded system. As such, we don't really have a good implementation of a thread-safe cache for caching expensive-to-create objects. That's the problem I'm looking to solve, and the solution? Guava. The Guava libraries [1] (under Apache 2.0 license) have well tested, intuitive classes that do a lot of the low-level mechanisms that we often need, and there's really no point in reinventing the wheel. The obvious cost of adding this library is the addition of a JAR in the class-path, as such I'm not calling for a vote at this point, I just wanted to know what the general consensus on this was. The Guava library is often heralded as the new Apache Commons and praised for being well maintained [2][3] but I'd suggest if anyone is sceptical of the benefits, to do some research. I accept, however, that developers can get a religious zeal about these kind of things, I'm not suggesting Guava is the cure to world poverty, just that it could help handle some of the lower-level tools. Though I'd love to spend time implementing fit-for-purpose mechanisms, these issues are usually bugs that our clients want fixed NOW!!! And so we find ourselves constantly saying ok, we'll do it this way for now, but next time we'll find a proper fix... This is a subject I've been wanting to bring up for a while, we've had to implement several thread-safe caching systems (for example in the pdf-image-plugin) but I wanted to wait for compelling reason. Though the reason above isn't any more compelling than for the pdf-image-plugin, I think the addition of this library would prevent some of the low-level mistakes that we all make sometimes. If anyone has questions, I'd be happy to explain
Re: svn commit: r1380169 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: events/CompositeEventListener.java pdf/PDFEncoding.java
My bad. Just fixed this
On 4 September 2012 10:49, Vincent Hennebert vhenneb...@gmail.com wrote:
On 03/09/12 09:38, mehdi wrote:
Author: mehdi
Date: Mon Sep 3 08:38:26 2012
New Revision: 1380169
URL: http://svn.apache.org/viewvc?rev=1380169view=rev
Log:
Amended a couple javadocs and some trivial clean up
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/events/CompositeEventListener.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/pdf/PDFEncoding.java
Modified:
xmlgraphics/fop/trunk/src/java/org/apache/fop/events/CompositeEventListener.java
URL:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/events/CompositeEventListener.java?rev=1380169r1=1380168r2=1380169view=diff
==
---
xmlgraphics/fop/trunk/src/java/org/apache/fop/events/CompositeEventListener.java
(original)
+++
xmlgraphics/fop/trunk/src/java/org/apache/fop/events/CompositeEventListener.java
Mon Sep 3 08:38:26 2012
@@ -19,6 +19,7 @@
package org.apache.fop.events;
+import java.util.ArrayList;
import java.util.List;
/**
@@ -26,7 +27,7 @@ import java.util.List;
*/
public class CompositeEventListener implements EventListener {
-private List listeners = new java.util.ArrayList();
+private ListEventListener listeners = new
ArrayListEventListener();
/**
* Adds an event listener to the broadcaster. It is appended to the
list of previously
@@ -46,22 +47,17 @@ public class CompositeEventListener impl
this.listeners.remove(listener);
}
-private synchronized int getListenerCount() {
-return this.listeners.size();
-}
-
/**
* Indicates whether any listeners have been registered with the
broadcaster.
* @return true if listeners are present, false otherwise
*/
public boolean hasEventListeners() {
-return (getListenerCount() 0);
+return !listeners.isEmpty();
}
By calling getListenerCount this method was made thread-safe. Now it no
longer is. Is that really intended?
-/** {@inheritDoc} */
+/** {@inheritDoc } */
Spurious change here.
public synchronized void processEvent(Event event) {
-for (int i = 0, c = getListenerCount(); i c; i++) {
-EventListener listener =
(EventListener)this.listeners.get(i);
+for (EventListener listener : listeners) {
listener.processEvent(event);
}
}
Thanks,
Vincent
