Re: getPageCount and FOP 1.0dev
I think I have a handle on how to obtain the number of pages generated per page sequence. However, I am struggling with how to best access the FormattingResults structure in Fop.java. In 0.20.5 the structure lived in StreamRenderer which is now sort of AreaTreeHandler. It is not clear to me how I can access AreaTreeHandler from Fop.java as it appears not to be accessible from what Fop.java currently holds? As an alternative the results structure could live in FOUserAgent as FOUserAgent is known to both Fop.java and AreaTreeHandler. However, FOUserAgent is currently used to only communicate user configurable items into the fo processing not to report back which is the purpose of the FormatingResults. As I am quite new to this I don't want to stuff things up and would appreciate suggestions. Thanks Manuel On Thu, 28 Jul 2005 03:41 am, Simon Pepping wrote: ... On Wed, Jul 27, 2005 at 08:43:50AM +0200, Jeremias Maerki wrote: Manuel, ... - Find a way to access the FormattingResults structure in Fop.java like it was done in 0.20.5.
DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics
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=35918. 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=35918 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 11:33 --- Thanks for the patch. Do you have an example that shows the effect of your change that you could attach to this issue? -- 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: Element list generation for tables (special case)
D'oh, right. :-) Lucky me. Too bad, we don't generate validation warnings for misplaced non-inherited properties. Didn't we have that discussion already this year? I can't find it or am I imagining it? On 30.07.2005 03:47:45 Andreas L Delmelle wrote: On Jul 28, 2005, at 14:04, Jeremias Maerki wrote: On 28.07.2005 13:42:08 Andreas L Delmelle wrote: Where it comes to rowspans: In my modified example, if you move all the text in the middle column to the first row and make that cell span two rows, things get a bit awkward without the proposed rule anyway... Ouch. You definitely hit a bug here. The height calculation rule should have placed the two Bs right under the As (i.e. first row height = 8pt). A bug in me, that's for sure! I misplaced the rowspan property :-) Sorry. Cheers, Andreas Jeremias Maerki
Re: Element list generation for tables (special case)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 29, 2005, at 23:25, Jeremias Maerki wrote: Strike that. Just found a mean case where my quick hack breaks. Back to frame one and a half. It's going to be a bit more difficult. FWIW: It occurred to me that, with a break-before=page on the fo:block in the second column/second row, the result you initially posted would be correct... at least, I think so :-/ This made me wonder if the rule has to be formulated differently. Let's make it: until we reach the first grid unit in the row that has a box that actually causes a break --either through a forced break or imposed by bpd constraints-- all break possibilities in previous grid units are ONLY possibilities. Those possibilities need to be taken into consideration, if and only if: 1) the breaking grid unit has previous boxes that still fit on the page 2) or the break was forced (or = inclusive) For the following grid units in the same row, we have enough information to decide if we need to break before their first box or not, so they do not necessarily have to have contributed their 'one box'. So, IIC, the grid units in a row each have to contribute ALL of their boxes until the first real break (more than a possible break). In the presented case, this comes down to the same thing as saying that they have to contribute one box, but that was a simplified case for demonstration purposes. If implementing the rule that way is possible, I think this would hold for most cases. HTH! Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC61+LyHTbFO9b8aARAqZ1AKCUS3ZNlH9czbSJhvfAS6PDLy57KQCgsqTw /J/AVs16QS3GtSTAUcipDMs= =UxX7 -END PGP SIGNATURE-
Re: Element list generation for tables (special case)
On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote: But I get the impression that this avoids the topic I raised. :-) I think this here is not about whether these special break conditions are favored or avoided but if they should be allowed at all. OK. Yes, the rule you propose sounds OK. Inside a row group, you may limit the rule to those columns which start a grid unit in this row, and exclude the columns which span into this row from a previous row. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Element list generation for tables (special case)
On Wed, Jul 27, 2005 at 10:40:25PM +0200, Jeremias Maerki wrote: I was under the impression that the breaker automatically favors break decisions that take up less space. It even goes so far that if you have a minimum=0pt and an optimum=2opt on a space-before, that it currently chooses 0pt which is not so good, actually. Penalties would help. If there were a penalty associated with the break below 'B', then the break above it becomes more favourable. I do not think the breaker could do that otherwise (without the newly proposed rule). Well, we have several documented examples on the Wiki which we could play through to see if the breaker is likely to make bad break decisions. But I get the impression that this avoids the topic I raised. :-) I think this here is not about whether these special break conditions are favored or avoided but if they should be allowed at all. On 27.07.2005 21:54:00 Simon Pepping wrote: One thing that IMHO is still lacking in the table breaking code is penalty values. ATM all penalties are 0. I believe the penalty value should depend on the extra vertical size that the break contributes, that is, on the penalty's width. I have no idea about the multiplication constant, nor if it should be linear or quadratic. I am not sure if it avoids the current case, but it is surely needed in order to favour better breaks over worse ones. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 35937] New: - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
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=35937. 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=35937 Summary: [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0 Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Patch to add the getResults() functionality to the apps.Fop object to mirror the similar functionality in the 0.20.5 apps.Driver object. See also this thread: http://marc.theaimsgroup.com/?l=fop-devm=112244484519341w=2 -- 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 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
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=35937. 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=35937 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 14:39 --- Created an attachment (id=15822) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15822action=view) Diff of changes made -- 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 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
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=35937. 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=35937 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 14:41 --- Created an attachment (id=15823) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15823action=view) FormattingResults.java - new class file -- 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 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
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=35937. 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=35937 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 14:41 --- Created an attachment (id=15824) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15824action=view) PageSequenceResults.java - New class file -- 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: Element list generation for tables (special case)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 30, 2005, at 11:51, Jeremias Maerki wrote: D'oh, right. :-) Lucky me. Too bad, we don't generate validation warnings for misplaced non-inherited properties. Didn't we have that discussion already this year? I can't find it or am I imagining it? I also remember this being mentioned... Yep, found it. A thread from about a month ago. http://marc.theaimsgroup.com/?l=fop-devm=111962589510266w=2 As Glen indicated, the XSL-FO Rec starts off by allowing any property on any object, but further on, it does state that for every class of objects there is a specific set of applicable properties. Thinking of ideas on implementing such checks... Currently, I don't think we already have a mapping of these object-applicable_props anywhere, and maybe we don't even need such a map. Since the PropertyList is a temporary list anyway, whose individual properties get bound to member variables of the respective objects, is it safe to say that the FObj subclass' member variables --or at least a subset-- corresponds to the set of applicable properties? If that is true, what we're looking for seems to be a possibility to check whether the list contains any unbound properties after the call to --or ending-- FObj.bind(). Shouldn't cost too much, I think. Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC630myHTbFO9b8aARArkpAJ94BITEvZauAi+oMfRSpStvUPKTywCcCGgG mMQvEojfDcJndutFEQtZatA= =3Rdr -END PGP SIGNATURE-
RE: getPageCount and FOP 1.0dev
As this is now done anything else I can help with (keep it small to start with please)? Manuel
Re: Element list generation for tables (special case)
On 30.07.2005 13:07:40 Andreas L Delmelle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 29, 2005, at 23:25, Jeremias Maerki wrote: Strike that. Just found a mean case where my quick hack breaks. Back to frame one and a half. It's going to be a bit more difficult. FWIW: It occurred to me that, with a break-before=page on the fo:block in the second column/second row, the result you initially posted would be correct... at least, I think so :-/ This made me wonder if the rule has to be formulated differently. Let's make it: until we reach the first grid unit in the row that has a box that actually causes a break --either through a forced break or imposed by bpd constraints-- all break possibilities in previous grid units are ONLY possibilities. Those possibilities need to be taken into consideration, if and only if: 1) the breaking grid unit has previous boxes that still fit on the page 2) or the break was forced (or = inclusive) Right, important point. I forgot about the hard breaks. My quick hack would also have failed with those. But I already have another idea how to fix this without too much effort. I'll try that on Tuesday when my brain isn't preoccupied with the weekend and the national holiday on Monday. :-) For the following grid units in the same row, we have enough information to decide if we need to break before their first box or not, so they do not necessarily have to have contributed their 'one box'. So, IIC, the grid units in a row each have to contribute ALL of their boxes until the first real break (more than a possible break). In the presented case, this comes down to the same thing as saying that they have to contribute one box, but that was a simplified case for demonstration purposes. If implementing the rule that way is possible, I think this would hold for most cases. I agree. HTH! Thanks. It does. Jeremias Maerki
Re: Element list generation for tables (special case)
Thanks for looking it up. I've put it on the todo list on the Wiki so it doesn't get forgotten. It's low priority anyway. It's probably a good exercise for someone who wants to get into how the FO tree works. On 30.07.2005 15:14:04 Andreas L Delmelle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 30, 2005, at 11:51, Jeremias Maerki wrote: D'oh, right. :-) Lucky me. Too bad, we don't generate validation warnings for misplaced non-inherited properties. Didn't we have that discussion already this year? I can't find it or am I imagining it? I also remember this being mentioned... Yep, found it. A thread from about a month ago. http://marc.theaimsgroup.com/?l=fop-devm=111962589510266w=2 As Glen indicated, the XSL-FO Rec starts off by allowing any property on any object, but further on, it does state that for every class of objects there is a specific set of applicable properties. Thinking of ideas on implementing such checks... Currently, I don't think we already have a mapping of these object-applicable_props anywhere, and maybe we don't even need such a map. Since the PropertyList is a temporary list anyway, whose individual properties get bound to member variables of the respective objects, is it safe to say that the FObj subclass' member variables --or at least a subset-- corresponds to the set of applicable properties? If that is true, what we're looking for seems to be a possibility to check whether the list contains any unbound properties after the call to --or ending-- FObj.bind(). Shouldn't cost too much, I think. Cheers, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC630myHTbFO9b8aARArkpAJ94BITEvZauAi+oMfRSpStvUPKTywCcCGgG mMQvEojfDcJndutFEQtZatA= =3Rdr -END PGP SIGNATURE- Jeremias Maerki
Re: getPageCount and FOP 1.0dev
You're making me happy, Manuel! May I point you to the task list on the Wiki? http://wiki.apache.org/xmlgraphics-fop/FOPProjectTasks I think there are lots of small things that you can easily jump into. Absolutely great would be if you tried to prepare the compliance page to receive additional columns so we can better communicate what FOP Trunk can do in comparison to FOP 0.20.5. I can certainly help filling out the gaps but if you tried to prepare the foundation, I'd love you for that. The only drawback for this one would be that you'd have to install Forrest to do that. Not a too steep learning curve anyway for someone familiar with XML and XSLT. More infos here: http://xml.apache.org/fop/dev/doc.html The file that would need to be changed is this one: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/documentation/content/xdocs/compliance.ihtml Stylesheets used with the above document: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/documentation/resources/stylesheets/ But you're welcome to choose anything else. Writing tests for and improving support for instream-foreign-object and external-graphic would also be very good. On 30.07.2005 15:40:12 Manuel Mall wrote: As this is now done anything else I can help with (keep it small to start with please)? Manuel Jeremias Maerki
DO NOT REPLY [Bug 35939] New: - [PATCH] Port of 0.20.5 Driver.java class
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=35939. 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=35939 Summary: [PATCH] Port of 0.20.5 Driver.java class Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] To be able to simply replace a 0.20.5 fop.jar with 1.0dev fop.jar I have written a backwards compatible apps.Driver.java class. Everything in the class has been labelled as deprecated. Even if you don't want to put it into the trunk its here in BugZilla so people who like me just want to quickly temporarily replace their 0.20.5 fop jar with 1.0dev without having to recode their application can grab it. -- 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 35940] New: - 1.0dev differences to 0.20.5
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=35940. 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=35940 Summary: 1.0dev differences to 0.20.5 Product: Fop Version: 1.0dev Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: pdf renderer AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] Had a first go at using 1.0dev as replacement for 0.20.5 and noticed a few problems with my sample: 1. Everything seems to be rendered in Times Roman font although the specified font selection is Verdana, Arial, Helvetica, sans-serif 2. A line is broken when it doesn't needed to, i.e. the text Victorian Land Index Property Address Search Result is broken into two lines although there is plenty of space to have it on one line 3. There is extra space between table rows, i.e. between the text mentioned above and the date/time line is an empty line in the pdf when it shouldn't be. I'll attached sample fo and pdfs. -- 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 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 17:45 --- Created an attachment (id=15826) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15826action=view) The sample FO file -- 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 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 17:46 --- Created an attachment (id=15828) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15828action=view) The PDF as generated with 0.20.5 -- 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 35940] - 1.0dev differences to 0.20.5
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=35940. 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=35940 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 18:26 --- Initial analysis: (In reply to comment #0) Had a first go at using 1.0dev as replacement for 0.20.5 and noticed a few problems with my sample: 1. Everything seems to be rendered in Times Roman font although the specified font selection is Verdana, Arial, Helvetica, sans-serif As 0.20.5, the trunk code doesn't support the comma-separated font lists, yet. It doesn't even see the Helvetica or sans-serif entries. It falls back to the default which seems to have been changed to serif. 2. A line is broken when it doesn't needed to, i.e. the text Victorian Land Index Property Address Search Result is broken into two lines although there is plenty of space to have it on one line Interesting. Only seems to happen for text-align=center. It doesn't happen with start or justify. Need to investigate that more closely. 3. There is extra space between table rows, i.e. between the text mentioned above and the date/time line is an empty line in the pdf when it shouldn't be. Same problem. Problem is only present with text-align=center. I'll attached sample fo and pdfs. Note to self: Create a layout engine testcase for this. -- 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: getPageCount and FOP 1.0dev
Managed to install Forrest 0.7 and installed and built the xmlgraphics site from http://svn.apache.org/repos/asf/xmlgraphics/site/. However, I am a bit confused about how this hangs together as there are two sites related to fop: xmlgraphics.apache.org and xml.apache.org/fop. So I can build with Forrest the xmlgraphics.apache.org site but I don't know how to build the xml.apache.org/fop site with Forrest. As the compliance page in question seems to reside under xml.apache.org/fop I am stuck. thks Manuel On Sat, 30 Jul 2005 10:11 pm, Jeremias Maerki wrote: ... The only drawback for this one would be that you'd have to install Forrest to do that. Not a too steep learning curve anyway for someone familiar with XML and XSLT. More infos here: http://xml.apache.org/fop/dev/doc.html The file that would need to be changed is this one: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/documentation/con tent/xdocs/compliance.ihtml Stylesheets used with the above document: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/documentation/res ources/stylesheets/ ...
Re: getPageCount and FOP 1.0dev
Ignore the XML Graphics site. Just run Forrest from the root directory where you checked out FOP. FOP's site is in its own repo, not in the site repo from XML Graphics. On 30.07.2005 18:38:55 Manuel Mall wrote: Managed to install Forrest 0.7 and installed and built the xmlgraphics site from http://svn.apache.org/repos/asf/xmlgraphics/site/. However, I am a bit confused about how this hangs together as there are two sites related to fop: xmlgraphics.apache.org and xml.apache.org/fop. So I can build with Forrest the xmlgraphics.apache.org site but I don't know how to build the xml.apache.org/fop site with Forrest. As the compliance page in question seems to reside under xml.apache.org/fop I am stuck. thks Manuel On Sat, 30 Jul 2005 10:11 pm, Jeremias Maerki wrote: ... The only drawback for this one would be that you'd have to install Forrest to do that. Not a too steep learning curve anyway for someone familiar with XML and XSLT. More infos here: http://xml.apache.org/fop/dev/doc.html The file that would need to be changed is this one: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/documentation/con tent/xdocs/compliance.ihtml Stylesheets used with the above document: http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/documentation/res ources/stylesheets/ ... Jeremias Maerki
DO NOT REPLY [Bug 35918] - [PATCH] Shapes are slightly shifted with respect to lines on larger graphics
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=35918. 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=35918 --- Additional Comments From [EMAIL PROTECTED] 2005-07-30 21:31 --- Created an attachment (id=15829) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15829action=view) sample FO, SVG and resulting PDF This bug is more complex than I have thought firstly. My patch helps only when using the Batik rasterizer (Batik 1.6 with patched pdf-transcoder.jar (alias fop-transcoder-allinone.jar in fop trunk)). commandline: java -jar batik-rasterizer.jar -m application/pdf bug35918.svg But if you use the FOP directly, the bug still exists. commandline: fop bug35918.fo bug35918.pdf -- 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 35948] New: - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 Summary: pre-patch for FOrayFont adaptation to Fop Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: general AssignedTo: fop-dev@xml.apache.org ReportedBy: [EMAIL PROTECTED] This is an early patch with the changes I've already made to adapt FOrayFont to Fop. Changes are mainly located in layoutmgr and pdf packages. This patch should not be applied: it is provided just in case committers want to see in the 3 next weeks what it looks like. -- 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 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 --- Additional Comments From [EMAIL PROTECTED] 2005-07-31 02:45 --- Created an attachment (id=15830) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15830action=view) patch against source files Please don't care about changes in the classes of the layoutmgr.inline subpackage: I have overwritten them with older versions on which I worked before they were moved to the inline subpackage. Next time I'll try to apply my changes to the trunk version instead of overwriting them. -- 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 35948] - pre-patch for FOrayFont adaptation to Fop
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=35948. 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=35948 --- Additional Comments From [EMAIL PROTECTED] 2005-07-31 02:46 --- Created an attachment (id=15831) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15831action=view) New files Newly created files: 2 java classes + the needed libraries from aXSL and FOray -- 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.
offline
Hi all, I'll be offline during 3 weeks: summer holidays, far from computers ;-) My work on the font subsystem is getting along, a bit slowly those last days but I hope to have more time after holidays. Currently I'm on the pdf part: it's a bit difficult because font and pdf things are very intermixed, and are handled each time a bit differently in Fop 0.20.5, Fop trunk and FOray. I don't know if the font subsystem will be ready for the next release, but I think that after the pdf part is done the rest should be easier to adapt. I'll do my best to make it ready. Just in case, I've put a patch on Bugzilla for those who might want to see my changes during these 3 next weeks. There are conflict issues, problems with the new layoutmgr.inline subpackage and the code won't compile. So this is really for curious guys that have time to loose ;-) See you in 3 weeks. Cheers, Vincent
