DO NOT REPLY [Bug 37579] footnotes within tables and listsl get lost
https://issues.apache.org/bugzilla/show_bug.cgi?id=37579 Ryan Lortie (desrt) <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Caching of pages with forward references
Yes, CachedRenderPagesModel lies around unused but it still works.
Here's some (uncleaned) example code that shows how to use it.
public class AreaTreeTests {
private static class MyAreaTreeHandler extends AreaTreeHandler {
public MyAreaTreeHandler(FOUserAgent userAgent, String outputFormat,
OutputStream stream) throws FOPException {
super(userAgent, outputFormat, stream);
}
protected void setupModel(FOUserAgent userAgent, String outputFormat,
OutputStream stream) throws FOPException {
//super.setupModel(userAgent, outputFormat, stream);
this.model = new CachedRenderPagesModel(userAgent, outputFormat,
fontInfo,
stream);
}
}
private static void doit() throws Exception {
FopFactory fopFactory = FopFactory.newInstance();
fopFactory.setUserConfig(new File("C:/Dev/FOP/main/userconfig.xml"));
final int maxRepeats = 100;
for (int repeat = 0; repeat < maxRepeats; repeat++) {
FOUserAgent ua = fopFactory.newFOUserAgent();
//String outputFormat = MimeConstants.MIME_FOP_AREA_TREE;
//outputFormat = MimeConstants.MIME_PDF;
String outputFormat = MimeConstants.MIME_POSTSCRIPT;
//File foFile = new
File("C:/Dev/FOP/main/xml-fop-temp/examples/fo/basic/readme.fo");
File foFile = new File("C:/Dev/FOP/temp/tree-model-check.fo");
//File outFile = new File("D:/out.at.xml");
File outFile = new File("D:/out.ps");
OutputStream out = new FileOutputStream(outFile);
out = new BufferedOutputStream(out);
try {
Fop fop = fopFactory.newFop(outputFormat, ua, out);
AreaTreeHandler atHandler = new MyAreaTreeHandler(ua,
outputFormat, out);
ua.setFOEventHandlerOverride(atHandler);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();
Source src = new StreamSource(foFile);
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(src, res);
} finally {
IOUtils.closeQuietly(out);
}
}
}
public static void main(String[] args) {
try {
doit();
} catch (Exception e) {
e.printStackTrace();
}
}
}
This should allow you to do a few experiments.
At any rate, this approach may help in certain situations (such as many
small page-sequences). But in situation with large page-sequences, it
won't help as the layout engine can't process the FO tree while it is
built and because finished FOs are not released before the page-sequence
is finished. Have fun.
On 17.09.2008 18:16:15 Dario Laera wrote:
> Hi all,
>
> in fop documentation site there are at least two page that talk about
> memory caching on disk for page that contains unresolved forward
> references:
> http://xmlgraphics.apache.org/fop/dev/design/layout.html#issue-area-recycle
> and http://xmlgraphics.apache.org/fop/dev/design/
> areas.html#caching . I was thinking that this was just a nice idea not
> implemented yet: my tests with hundreds of single page page-sequences
> was often ending in OutOfMemory due to the "Page X of Y" block in the
> footer. But looking at the code in FOP trunk I found the class
> CachedRenderPagesModel that seems to do that caching; unfortunately
> this class is never instantiated.
> Was this class intended for unresolved forward reference issue? What
> is missing for having this kind of caching working? Is someone working
> on it?
>
> Thanks in advances
> Dario
Jeremias Maerki
DO NOT REPLY [Bug 45770] "Image not found" when using Java embedding
https://issues.apache.org/bugzilla/show_bug.cgi?id=45770 --- Comment #2 from M.H. <[EMAIL PROTECTED]> 2008-09-17 11:07:39 PST --- I found the cause: the problem is, that the new FOP doesn't accept relative URLs anymore ... at least when using with Java embedding - with the fop.batr command line command, it works. After writing my own URIResolver to workaround this probem (by appending a fixed URL string as a prefix) I got it to work again. However, this is a rather bad workaround. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45795] Fails to read some .png files
https://issues.apache.org/bugzilla/show_bug.cgi?id=45795 Jeremias Maerki <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-09-17 09:47:50 PST --- This is now fixed in FOP Trunk: http://svn.apache.org/viewvc?rev=696365&view=rev Thanks for the test file. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Caching of pages with forward references
Hi all, in fop documentation site there are at least two page that talk about memory caching on disk for page that contains unresolved forward references: http://xmlgraphics.apache.org/fop/dev/design/layout.html#issue-area-recycle and http://xmlgraphics.apache.org/fop/dev/design/ areas.html#caching . I was thinking that this was just a nice idea not implemented yet: my tests with hundreds of single page page-sequences was often ending in OutOfMemory due to the "Page X of Y" block in the footer. But looking at the code in FOP trunk I found the class CachedRenderPagesModel that seems to do that caching; unfortunately this class is never instantiated. Was this class intended for unresolved forward reference issue? What is missing for having this kind of caching working? Is someone working on it? Thanks in advances Dario
DO NOT REPLY [Bug 45770] "Image not found" when using Java embedding
https://issues.apache.org/bugzilla/show_bug.cgi?id=45770 Jeremias Maerki <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Jeremias Maerki <[EMAIL PROTECTED]> 2008-09-17 08:14:33 PST --- I'm not sure what the problem could be. Relative URIs work just fine for me. Can you try the following: - Set the Base URL on the FopFactory rather than on the FOUserAgent. That shouldn't make any difference for images, though, as they use the base URL from the FOUserAgent. - Remove any base URL from the configuration file if you use one. Shouldn't really make a difference, either. But redundance can sometimes make for nasty surprises. If this doesn't help (and it probably won't), the only thing that comes to my mind is setting a break point in FOUserAgent.resolveURI(String, String) and check what exactly is going on. Please reopen this issue if you doesn't lead you to the problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45759] [PATCH] Internal PDF links from included SVG graphics
https://issues.apache.org/bugzilla/show_bug.cgi?id=45759 Stefan Bund <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #22538|text/plain |application/octet-stream mime type|| Attachment #22538|1 |0 is patch|| -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45759] [PATCH] Internal PDF links from included SVG graphics
https://issues.apache.org/bugzilla/show_bug.cgi?id=45759 Stefan Bund <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45759] [PATCH] Internal PDF links from included SVG graphics
https://issues.apache.org/bugzilla/show_bug.cgi?id=45759 Stefan Bund <[EMAIL PROTECTED]> changed: What|Removed |Added Attachment #22538|application/octet-stream|application/x-gzip mime type|| -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45770] New: "Image not found" when using Java embedding
https://issues.apache.org/bugzilla/show_bug.cgi?id=45770 Summary: "Image not found" when using Java embedding Product: Fop Version: 0.95 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I tested FOP 0.95 after migrating the XSL files from 0.20.5 and all went very well when tested with the fop.bat included with FOP 0.95 - including the SVG and GIF images. Then I started migrating the Java application from FOP 0.20.5 to FOP 0.95 and now all the images are missing. The baseUrl is set up correctly in the used fopUserAgent (I tried both "file:///" + oldFopBaseDir and "file:/" + oldFopBaseDir leading to "file:///C:\temp", "file:/C:\temp"). As the reports also include other XSL files with relative URLs, the userAgents baseURL seems basically to work. So I wonder why FOP 0.95 can't find the images: Image not found: images/top.svg Image not found: images/singlearr.gif Again: the same baseDir used to create the report with fop.bat works including all the images. So, it's not a bug with the XSL/image files but with the Java embedding config. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Code Duplication [Re: svn commit: r680339 - in /xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/render: AbstractPathOrientedRenderer.java intermediate/IFGraphicContext.java int
Hi,
(Still catching up with the commits of the past month...)
I’d like to take this commit as an opportunity to launch the debate
about copy-pasting:
> Date: Mon Jul 28 06:03:40 2008
> New Revision: 680339
> Modified:
> xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/render/intermediate/IFRenderer.java
> URL:
> http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/render/intermediate/IFRenderer.java?rev=680339&r1=680338&r2=680339&view=diff
> ==
> ---
> xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/render/intermediate/IFRenderer.java
> (original)
> +++
> xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/render/intermediate/IFRenderer.java
> Mon Jul 28 06:03:40 2008
> @@ -361,9 +395,120 @@
>
> /** [EMAIL PROTECTED] */
> protected void renderBlockViewport(BlockViewport bv, List children) {
> +//Essentially the same code as in the super class but optimized for
> the IF
More than 80% of the code of this method is completely identical to the
overridden method. Surely there’s a way to optimize it and avoid that
code duplication in the same time...
I can’t think of any good reason for copy-pasting code. That
artificially increases the size of the codebase, that makes the code
more difficult to understand and much more tricky to maintain. As soon
as a change is made somewhere, you’re almost sure that at least one
duplicated part will be forgotten somewhere.
There is already way too much code duplication in the present codebase.
Let’s avoid introducing even more duplication in new commits, shall we?
Thanks,
Vincent
Re: Code Duplication [Re: svn commit: r680339 - in /xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/java/org/apache/fop/render: AbstractPathOrientedRenderer.java intermediate/IFGraphicContext.java
Jeremias Maerki wrote:
> On 09.09.2008 13:01:54 Vincent Hennebert wrote:
>>> /** [EMAIL PROTECTED] */
>>> protected void renderBlockViewport(BlockViewport bv, List children) {
>>> +//Essentially the same code as in the super class but optimized
>>> for the IF
>> More than 80% of the code of this method is completely identical to the
>> overridden method. Surely there’s a way to optimize it and avoid that
>> code duplication in the same time...
>
> I've spent a lot of time in implementations of renderBlockViewport in
> the past. I've been able to make small improvements over time but I've
> never found a solution that fits all output formats so far. Without any
> major refactoring of the code anyway, which is basically what I'm doing
> in the branch right now.
>
>> I can’t think of any good reason for copy-pasting code. That
>> artificially increases the size of the codebase, that makes the code
>> more difficult to understand and much more tricky to maintain. As soon
>> as a change is made somewhere, you’re almost sure that at least one
>> duplicated part will be forgotten somewhere.
>
> Don't you think I know that copy/paste programming is bad?
That’s precisely why I don’t understand why there’s so much of that to
be found in the current code. Performance is not an argument if you ask
me. We’re not developing a software that will run on a micro-controller,
with a 68000 processor and where memory is counted in Kb instead of Gb.
The complexity of the topic makes it much more important to have
a codebase that is clean and conceptually simple. Anyway, there’s IMO
much more to achieve in terms of performance by working on the software
architecture rather than replacing a few method calls, early exiting
a loop, or whatever.
>> There is already way too much code duplication in the present codebase.
>> Let’s avoid introducing even more duplication in new commits, shall we?
>
> I'm trying all the time. Please note: the branch is work in progress and
> once it's done many renderer implementations will get deprecated to
> lighten the maintainance burden. Eventually they'll get removed and the
> copy/paste problem goes away.
Then where is the TODO comment explaining exactly that? That would have
saved me the time to write this message, and saved you the time to
answer it. I can’t read in your mind...
Vincent
Re: svn commit: r690319 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/table/ test/layoutengine/standard-testcases/
I knew full well when I committed this that there's a certain probability that you're not going to be happy with how I dit it. It's hard to please you these days. So, is this post of yours a veto? At any rate, I don't think that generating FOs for missing table cells is the right approach. As can be seen in my commit, it is perfectly possible to do without the additional overhead involved with your solution. And I don't think the code is ugly because of that. On 11.09.2008 14:11:31 Vincent Hennebert wrote: > Hi, > > > Author: jeremias > > Date: Fri Aug 29 09:36:17 2008 > > New Revision: 690319 > > > > URL: http://svn.apache.org/viewvc?rev=690319&view=rev > > Log: > > Added missing generation of areas for empty grid units in tables with > > collapsing border model. > > > I’m not happy with that change. Basically it’s code copy-pasted from > several places and slightly modified to handle missing cells. I didn’t > spend months trying to clean up the table layout code to see that kind > of change introduced at the first opportunity... > > A bit of background first: distinction needs to be made between /empty/ > cells (existing table-cell elements with no content), and /missing/ > cells (missing table-cell element; e.g., only three cells on a row in > a four-column table). The EmptyGridUnit class is meant to handle that > latter case only (yes, it’s misnamed). I didn’t have the opportunity of > addressing that issue when I worked on tables, so I left it as is. > > That EmptyGridUnit class doesn’t fit well in the big picture. It > constantly requires special care just because you can’t get a non-null > TableCell object from it. The only way I could think of to handle that > properly is to ‘fix’ the FO tree, completing it by adding empty > table-cell elements. Basically in FixedColRowGroupBuilder.endRow(), > instead of filling the gaps with EmptyGridUnit objects, proper TableCell > objects would be created in some way. > > To achieve that we need to be able to create FONode objects outside of > the FOTreeBuilder machinery. Or to trigger the proper events on > FOTreeBuilder so that new TableCell objects are ‘automatically’ created. > I haven’t had the opportunity to look into it into more details, but I’d > rather explore this possibility, instead of dealing with EmptyGridUnit. > If FO tree specialists have any comments or suggestions... > > > Thanks, > Vincent Jeremias Maerki
Re: svn commit: r690319 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/table/ test/layoutengine/standard-testcases/
Jeremias Maerki wrote: > I knew full well when I committed this that there's a certain > probability that you're not going to be happy with how I dit it. It's > hard to please you these days. So, is this post of yours a veto? Depends. The thing is, this issue will most probably show up also with the new layout approach, and it would be good to have it sorted out before. > At any rate, I don't think that generating FOs for missing table cells > is the right approach. Why? > As can be seen in my commit, it is perfectly > possible to do without the additional overhead involved with your > solution. But not without additional code duplication. > On 11.09.2008 14:11:31 Vincent Hennebert wrote: >> Hi, >> >>> Author: jeremias >>> Date: Fri Aug 29 09:36:17 2008 >>> New Revision: 690319 >>> >>> URL: http://svn.apache.org/viewvc?rev=690319&view=rev >>> Log: >>> Added missing generation of areas for empty grid units in tables with >>> collapsing border model. >> >> >> I’m not happy with that change. Basically it’s code copy-pasted from >> several places and slightly modified to handle missing cells. I didn’t >> spend months trying to clean up the table layout code to see that kind >> of change introduced at the first opportunity... >> >> A bit of background first: distinction needs to be made between /empty/ >> cells (existing table-cell elements with no content), and /missing/ >> cells (missing table-cell element; e.g., only three cells on a row in >> a four-column table). The EmptyGridUnit class is meant to handle that >> latter case only (yes, it’s misnamed). I didn’t have the opportunity of >> addressing that issue when I worked on tables, so I left it as is. >> >> That EmptyGridUnit class doesn’t fit well in the big picture. It >> constantly requires special care just because you can’t get a non-null >> TableCell object from it. The only way I could think of to handle that >> properly is to ‘fix’ the FO tree, completing it by adding empty >> table-cell elements. Basically in FixedColRowGroupBuilder.endRow(), >> instead of filling the gaps with EmptyGridUnit objects, proper TableCell >> objects would be created in some way. >> >> To achieve that we need to be able to create FONode objects outside of >> the FOTreeBuilder machinery. Or to trigger the proper events on >> FOTreeBuilder so that new TableCell objects are ‘automatically’ created. >> I haven’t had the opportunity to look into it into more details, but I’d >> rather explore this possibility, instead of dealing with EmptyGridUnit. >> If FO tree specialists have any comments or suggestions... >> >> >> Thanks, >> Vincent > > > > > Jeremias Maerki Vincent
Re: svn commit: r690319 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/table/ test/layoutengine/standard-testcases/
On 11.09.2008 22:59:31 Vincent Hennebert wrote: > Jeremias Maerki wrote: > > I knew full well when I committed this that there's a certain > > probability that you're not going to be happy with how I dit it. It's > > hard to please you these days. So, is this post of yours a veto? > > Depends. The thing is, this issue will most probably show up also with > the new layout approach, and it would be good to have it sorted out > before. > > > > At any rate, I don't think that generating FOs for missing table cells > > is the right approach. > > Why? Elaborating on "additional overhead": You would generate additional FOs for non-existent table-cells. For each FO, a layout manager is created which will also need to be called. Table layout will need to run through more cells per row than necessary even though they're empty. More objects, more CPU cycles. Granted we're probably not talking about a lot of empty table-cells but still. RowPainter is area-generation stage. My solution is just making sure areas are generated with the information that is available anyway. It's not doing anything in a place where it shouldn't do it. The change is confined to a narrow space. Your solution spans FO tree, layout and area generation. So I'm not convinced that my solution is bad or that your solution is better. > > As can be seen in my commit, it is perfectly > > possible to do without the additional overhead involved with your > > solution. > > But not without additional code duplication. > > > > On 11.09.2008 14:11:31 Vincent Hennebert wrote: > >> Hi, > >> > >>> Author: jeremias > >>> Date: Fri Aug 29 09:36:17 2008 > >>> New Revision: 690319 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=690319&view=rev > >>> Log: > >>> Added missing generation of areas for empty grid units in tables with > >>> collapsing border model. > >> > >> > >> I’m not happy with that change. Basically it’s code copy-pasted from > >> several places and slightly modified to handle missing cells. I didn’t > >> spend months trying to clean up the table layout code to see that kind > >> of change introduced at the first opportunity... > >> > >> A bit of background first: distinction needs to be made between /empty/ > >> cells (existing table-cell elements with no content), and /missing/ > >> cells (missing table-cell element; e.g., only three cells on a row in > >> a four-column table). The EmptyGridUnit class is meant to handle that > >> latter case only (yes, it’s misnamed). I didn’t have the opportunity of > >> addressing that issue when I worked on tables, so I left it as is. > >> > >> That EmptyGridUnit class doesn’t fit well in the big picture. It > >> constantly requires special care just because you can’t get a non-null > >> TableCell object from it. The only way I could think of to handle that > >> properly is to ‘fix’ the FO tree, completing it by adding empty > >> table-cell elements. Basically in FixedColRowGroupBuilder.endRow(), > >> instead of filling the gaps with EmptyGridUnit objects, proper TableCell > >> objects would be created in some way. > >> > >> To achieve that we need to be able to create FONode objects outside of > >> the FOTreeBuilder machinery. Or to trigger the proper events on > >> FOTreeBuilder so that new TableCell objects are ‘automatically’ created. > >> I haven’t had the opportunity to look into it into more details, but I’d > >> rather explore this possibility, instead of dealing with EmptyGridUnit. > >> If FO tree specialists have any comments or suggestions... > >> > >> > >> Thanks, > >> Vincent > > > > > > > > > > Jeremias Maerki > > Vincent Jeremias Maerki
DO NOT REPLY [Bug 45789] New: FOP crashing with exception when embedding PNG
https://issues.apache.org/bugzilla/show_bug.cgi?id=45789 Summary: FOP crashing with exception when embedding PNG Product: Fop Version: 0.95 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I'm including a PNG file in a document and FOP is crashing with the following exception. This previously worked in fop 0.94. Note that there's a typo in the error message and that could also be fixed. java.lang.IllegalStateException: The resolution mus be set at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:217) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:125) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) - java.lang.IllegalStateException: The resolution mus be set at org.apache.xmlgraphics.image.loader.ImageSize.calcSizeFromPixels(ImageSize.java:210) The PNG file in question was created using Dia. pngcheck for the image shows: OK: a.png (567x400, 24-bit RGB, non-interlaced, 96.0%) pngmeta showed nothing. My guess is that there is no information in the image to indicate DPI. Surely, in this situation, it should just be guessing. The XSL-FO used is as follows: Given that it is scaling, I would have thought that the resolution should be irrelevant. The XSL-FO file came from Docbook-xsl but I can reproduce it by copying the file into a hello world XSL-FO file. I'd prefer not to post the image file publicly but if anyone needs it, I can e-mail it privately. Oliver Kiddle -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Bug report for Fop [2008/09/14]
>> >> >> *Location: Jumeirah Park – JPL4V001* >> >> *Plot Area: 8,098.98 Sq.Ft* >> >> *Total Floor Area: 4,335 square Feet* >> >> *4 Bed Room* >> >> *Theme: Arabic* >> >> *Style: GENERAL* >> >> *Option Type: Swimming Pool* >> >> *Original price : AED 4,065,700 * >> >> *Asking price is 7.15 Net to owner.* >> >> *Transfer fee 2% from original price = 81,314 Aed.* >> >> ** >> >> *FAROOQ* >> >> *050-8733350* >> >> [EMAIL PROTECTED] >> >> [EMAIL PROTECTED] >> >> ** >> >> >> >> * * >> >> * * >> >> * * >> >> * * >> >> * * >> >> >> >> >> >> >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Dubai Realrly using | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver | |14529|New|Nor|2002-11-13|SVG url references do not work| |14679|New|Enh|2002-11-19|Pluggable renderers | |14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends | |15020|New|Enh|2002-12-03|Reuse of fo-tree | |16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer | |16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's | |16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|"visibility" property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER & README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align="end" | |24171|New|Nor|2003-10-28|[PATCH] 1st Attempt at Whole Site PDF | |24378|New|Nor|2003-11-04|Minor problem in sample code for embedding| |24663|New|Nor|2003-11-12|fo:block space-after property needs fixing| |24804|New|Nor|2003-11-18|SVG Text to PS Output generates incorrect outlines| |25022|New|Nor|2003-11-26|XSL-FO to PCL : images not included | |25341|New|Nor|2003-12-08|percentage resolution not being recalculated on di| |25411|New|Nor|2003-12-10|[WARNING] Error while constructing image from XML | |25432|Ass|Maj|2003-12-11|Cannot embed the User Defined Characters into the | |26047|New|Nor|2004-01-11|Space-after value remembered and used on second do| |26590|New|Nor|2004-02-02|last character width in winansi font is missed| |26848|New|Nor|2004-02-11|PNG images using JIMI instead JAI |
Suport For Saxon in future FOP release
Hi, I noticed that during the ant build of the trunk, Saxon is used. Since Saxon is an xslt 2.0 processor, is there any plans to replace Xalan with Saxon as the default processor with future releases of FOP? Thanks, Phil -- View this message in context: http://www.nabble.com/Suport-For-Saxon-in-future-FOP-release-tp19329624p19329624.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Bug report for Fop [2008/09/07]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8463|New|Nor|2002-04-24|SVG clipping in external.fo example doc when rende| | 8767|Ass|Min|2002-05-03|Image and solid colour background rectangle sizes | | 9379|New|Nor|2002-05-24|MIF Renderer generates incorrect MIF code | |10379|New|Enh|2002-07-01|Improvement to FOP Classloader| |12494|New|Nor|2002-09-10|fop produces pdf file which Acrobat Reader refuses| |12610|New|Enh|2002-09-13|[PATCH] onLoad Action for PDF documents or how to | |13586|New|Blk|2002-10-13|fop will not work on linux alpha because jre is br| |13734|New|Nor|2002-10-17|Hyphenation does not work correctly on long string| |14248|New|Enh|2002-11-05|51-page FO example, could be added to the samples | |14352|New|Enh|2002-11-07|It would be nice if FOP could be plugged into popu| |14356|New|Nor|2002-11-07|*NOT* embedding TrueTypeFont in PDF causes Acrobat| |14419|New|Enh|2002-11-10|Implement SourceResolver, Image Resolver | |14529|New|Nor|2002-11-13|SVG url references do not work| |14679|New|Enh|2002-11-19|Pluggable renderers | |14924|New|Nor|2002-11-28|Table disappears when it ends when the page ends | |15020|New|Enh|2002-12-03|Reuse of fo-tree | |16017|Opn|Nor|2003-01-13|Jpeg's and the PDF Serializer | |16130|New|Nor|2003-01-15|PS-Renderer emits lots of redundant moveto's | |16156|New|Nor|2003-01-16|0.20.5rc SVG example does not work| |16713|New|Nor|2003-02-03|Hyphenation error in tables | |17369|New|Nor|2003-02-25|Footnote duplication | |17380|New|Nor|2003-02-25|Batik Component will not recognize fe SVG elem| |17921|New|Nor|2003-03-12|Kerning is broken for standard fonts | |18292|New|Nor|2003-03-24|24 bit PNG not displayed correctly| |18801|New|Nor|2003-04-08|"visibility" property is not implemented | |19228|New|Blk|2003-04-22|[PATCH] Child LayoutContext is null in certain cir| |19341|Ver|Nor|2003-04-26|leader doesn't work since 0.20.5.rc2 | |19695|New|Enh|2003-05-06|[PATCH] Allow fox:destination as child of fox:outl| |19717|New|Enh|2003-05-07|Lets add support for JimiClassesPro.zip to build.x| |19769|Ass|Enh|2003-05-08|Indefinite page size is not implemented | |20280|Ass|Enh|2003-05-27|text-align and text-align-last only partially impl| |20407|New|Enh|2003-06-02|[PATCH] Configure image caching using the configur| |20827|New|Enh|2003-06-17|Derive other font styles and weights from normal T| |21265|Opn|Nor|2003-07-02|referencing a custom font (TTF or Adobe Type 1) fo| |21905|New|Nor|2003-07-26|large list-item-label bleeds into following block | |21982|New|Maj|2003-07-30|NullPointer Exception in LazyFont with embedded fo| |22450|New|Maj|2003-08-15|Unterminated iteration in JPEGReader class| |22627|Opn|Nor|2003-08-21|Update mirror/download page HEADER & README (was [| |24148|New|Nor|2003-10-27|Kerning upsets text-align="end" | |24171|
DO NOT REPLY [Bug 45759] [PATCH] Internal PDF links from included SVG graphics
https://issues.apache.org/bugzilla/show_bug.cgi?id=45759 --- Comment #1 from Stefan Bund <[EMAIL PROTECTED]> 2008-09-08 01:58:08 PST --- Created an attachment (id=22538) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22538) patch against r693020 fop trunk -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: svn commit: r690319 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/layoutmgr/table/ test/layoutengine/standard-testcases/
Hi Andreas, (Answering both of your messages in one.) Andreas Delmelle wrote: > On Sep 16, 2008, at 12:05, Vincent Hennebert wrote: > >> >> I think this is negligible, precisely because we’re not talking about >> a lot of missing cells. This would start to be noticeable if we were >> dealing with huge empty tables, and in that case there’s probably >> something wrong with the source document. > > Not necessarily. Maybe the author was just trying to be creative > (avoiding a trip through SVG, by using tables as a medium-resolution > grid; something like that?) I know users can be very creative when it comes to using tables. Still. Assuming there’s a use case for the example you describe, this will probably be to achieve a fancy layout in a magazine-like document. Not a 10 thousand page document then, and the overhead won’t be noticeable. Also, let’s not forget that we’re dealing with a corner case here. In most cases empty table-cell elements /will/ be added by the XSLT stylesheet that produces the FO document anyway. The fact that this issue occurred only recently is a confirmation of that. Hence why the mentioned overhead isn’t really an issue, and why specific code should be kept to a minimum. > Sounds about right to me. Besides that, the instance size of > a TableCell > is large enough to justify not generating any more of these than > strictly necessary. Let alone increase the amount of memory used by the > FO tree even further if we would also start generating implicit empty > Blocks... Now /that/ is maybe the place for optimizations: improve the FO tree. For example make sure that no object is created if a property has its default value; or use a common read-only object for the default value. All the FO tree would benefit from that kind of optimization. But I’m not a specialist of that area... >>> RowPainter is area-generation stage. My solution is just making sure >>> areas are generated with the information that is available anyway. It's >>> not doing anything in a place where it shouldn't do it. > > Ultimately, that is the only place where this should have effects, I think. > Seems like we don't really need dummy nodes for anything layout-related, > so why precisely should they exist at that point? > Unless a darn' *good* answer to this question is given (i.e. a point > other than a rigid adherence to the 'no-duplication' rule) But this is exactly that. A rigid, strict, blind adherence to the ‘no-duplication’ rule. Because code duplication almost always is a sign that something is wrong in the architecture. Because something that looks like just a little redundancy generally reveals a deeper problem, that grows with time and eventually may totally prevent the implementation of new features. >> At any rate, this is not worth >> the additional maintenance required by specific code. > > Could be right here, but such considerations are always worth some > thought... I already partly answered that above by mentioning the corner case; more below. > What is the more precise description of this 'additional maintenance' in > this case? > Is it really /that/ much that it justifies the generation of additional > relatively large and long-lived objects so early in the process? > (Objects that basically correspond to nothing at all; maybe due to code > that was added just to make the code look cleaner... ;-)) What do you mean? > If still yes, then is there really no other approach? There is almost always another approach ;-). As I said I didn’t have the opportunity to think much about that, and that’s the idea that immediately came to my mind. Now there’s probably a way to handle that in GridUnit, but the getCell() method only is already called in quite a few places. > If no, then would it be better to do it now (before refactoring the > layoutengine) or after? > > Maybe if we leave it, but take note for now, a better solution will > become apparent once the refactoring is done (?) Maybe, but usually the discussion is carried out prior to the commit... And in that case proper TODOs are placed at proper places in the code. And possibly a bug report opened. > >> [Jeremias: ] >>> RowPainter is area-generation stage. My solution is just making sure >>> areas are generated with the information that is available anyway. It's >>> not doing anything in a place where it shouldn't do it. >> >> RowPainter deals with rows, not cells. All it does is select the cells >> for which it’s time to create areas, then it delegates to TableCellLM >> the actual area creation. With the change we’re discussing there are now >> two places where areas for cells are created: in TableCellLM /and/ in >> RowPainter. This is redundant, confusing and increases the maintenance >> code. > > Hmm... maybe an idea to consolidate those parts into a CellPainter, > then? Just a vague idea (?) Yes, something like that, probably. > Also an additional object, but for the empty cells, can be tailored to > be as lean/li
