DO NOT REPLY [Bug 40517] New: - link to a page-sequence doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40517. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40517 Summary: link to a page-sequence doesn't work Product: Fop Version: 0.20.5 Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: pdf AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] I'm using the docbook-xsl stylesheets to create my XSL-FO files. FOP is not handling links where the destination id is in a fo:page-sequence element. This means that in the table of contents, the page numbers are missing for all the chapter headings. Similarly, the cross-referencing is broken so clicking on the chapter heading in the table of contents or the PDF bookmark doesn't work. Looking at the generated XSL-FO, there is for example the following for the PDF bookmark: fox:outline internal-destination=id219576fox:label1.#xA0;Introduction/fox:label And, similarly in the table of contents: fo:basic-link internal-destination=id2195761. Introduction/fo:basic-link And the destination is in a fo:page-sequence: fo:page-sequence id=id219576 I can hack around the problem by adding the id to the fo:block that surrounds the title of the chapter later on the page but it'd be better if it could handle the destination being in the page-sequence. I'm no expert on XSL-FO so I'm assuming this is valid (and hence not a docbook-xsl bug). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Committing again..
I hope it's ok if I commit my work on OpenType fonts directly - I haven't committed anything here for a looong time, but still have commit rights. I'll do my best not to break anything, and also to include automated tests for my changes. -Bertrand
Re: Configuration file problems
I wouldn't go that far. A proper schema validation already tells you if you have an element in the wrong place. Besides that I guess what I want most is that users read and interpret error messages. :-) On 13.09.2006 20:31:03 Simon Pepping wrote: On Tue, Sep 12, 2006 at 09:37:20PM +0200, Jeremias Maerki wrote: On 12.09.2006 21:13:35 Simon Pepping wrote: Re extensibility: A XML file is validated according to the DTD or schema that it declares (Relax-NG is an exception). The user can put a DTD or schema of his own choice in the user configuration file: !DOCTYPE fop PUBLIC '-//MYSELF//DTD My FOP Configuration XML V1.0//EN' 'http://myserver.mydomain.eu/fop-configuration.dtd' and the parser will validate against it. This means that a user can extend the configuration file at will, and that FOP cannot be assured that the config file is valid. Embedded users can always avoid validation. Yes, but you already assume a non-novice user. If our goal is to have less problems, fewer support requests because of configuration errors, we have to do it fool-proof. You can't rely on everyone putting the DTD or XSD on top of the configuration file. The first time the XML doesn't validate, people remove the schema reference. This sounds like you want to catch user errors in any case. That would be a custom program that applies heuristics based on knowledge of common user errors. For example, 'Do you mean to configure font XXX? I found a font configuration element in a position where FOP will not pick it up.' Class UserConfigDoctor. A possibility besides Java is to do it in XSLT, in the manner of Schematron. Write templates for known suspect XPaths in the file, such as all font elements not in /*/renderers/renderer/fonts. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu Jeremias Maerki
Re: Configuration file problems
Oops. On 14.09.2006 02:23:49 Manuel Mall wrote: snip/ This made me look at our 'upgrading' page. It does NOT(!) mention that the config file format has changed! Seems to me the easiest fix to all of this is to actually tell users that they also have to change the config file used with 0.20.5 when upgrading. Jeremias Maerki
DO NOT REPLY [Bug 40517] - link to a page-sequence doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40517. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40517 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-09-15 18:55 --- FOP 0.20.5 is no longer maintained. All efforts go into the development of the trunk (0.92beta). The latest release is able to reference page-sequences but has problem with a few other id-bearing FO elements. Due to a problem with page-number-citations, 0.92beta and later is probably not ideal for DocBook applications, yet. You can try if the result is better with the latest release (or FOP Trunk from the Subversion repository) but there are no guarantees. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40495] - PDF Report - OutOfMemoryError
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40495. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40495 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-09-15 18:59 --- Please use the fop-users mailing list for asking questions on FOP. If you search the mailing list archives of the fop-users mailing list, you'll find tons of good suggestions to avoid OutOfMemoryErrors. http://www.nabble.com/forum/Search.jtp?forum=353local=yquery=OutOfMemoryError -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40491] - Out of Memory when add the attribute keep-together.within-column=always
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40491. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40491 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-09-15 19:08 --- I believe your FO file triggers an infinite loop. The OutOfMemoryError is only a side-effect. Please note that we don't fix any bugs for 0.20.5 anymore. At any rate, you have to make sure that with your keeps the content doesn't get longer than what room is available on the page. Even the latest release has problems with such a situation. However, when I fixed the FO errors in your example file, a PDF was generated with the latest FOP trunk (but not 0.92beta). Not that the result was great or anything. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: svn commit: r446682 - in /xmlgraphics/fop/trunk/src/documentation/content/xdocs: 0.92/upgrading.xml trunk/upgrading.xml
Author: jeremias Date: Fri Sep 15 11:53:15 2006 New Revision: 446682 URL: http://svn.apache.org/viewvc?view=revrev=446682 Log: mention that the config file format has changed. snip/ + If you are using a configuration file, you have rebuild it in the new format. The format A small typo: you have /to/ rebuild it... snip/ Vincent
