Re: Change bars support in FOP?
Hi Alexey, Reading the JIRA entry its clear that we are still waiting for some test cases. That is why the bug is in NEEDSINFO status. If they are provided then the patch could be reviewed again to check it is still compliant with the trunk code. Thanks, Chris On 11/03/2013 16:45, Alexey Neyman wrote: Thanks. That issue does not have any further comments/changes than the one in Bugzilla, though. Regards, Alexey. On Monday, March 11, 2013 01:24:20 am Pascal Sancho wrote: Hi, Just for convenience, you should monitor the corresponding issue in Jira: https://issues.apache.org/jira/browse/FOP-1760 Bugzilla Fop issues became read-only when we migrated them to Jira. 2013/3/10 Alexey Neyman sti...@att.net Hi, Are there any plans to implement change bars in FOP? I found the bug in JIRA that claims to implement that: https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 It is in NEEDSINFO state for almost a year now, even though the author has updated the patch and (presumably) addressed the review feedback on the previous version of the patch (which is why it was switched to NEEDSINFO, as far as I understand). Is this patch going to be integrated? Regards, Alexey. - 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
Re: Change bars support in FOP?
Hi, Just for convenience, you should monitor the corresponding issue in Jira: https://issues.apache.org/jira/browse/FOP-1760 Bugzilla Fop issues became read-only when we migrated them to Jira. 2013/3/10 Alexey Neyman sti...@att.net Hi, Are there any plans to implement change bars in FOP? I found the bug in JIRA that claims to implement that: https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 It is in NEEDSINFO state for almost a year now, even though the author has updated the patch and (presumably) addressed the review feedback on the previous version of the patch (which is why it was switched to NEEDSINFO, as far as I understand). Is this patch going to be integrated? Regards, Alexey. -- pascal
Re: Change bars support in FOP?
Thanks. That issue does not have any further comments/changes than the one in Bugzilla, though. Regards, Alexey. On Monday, March 11, 2013 01:24:20 am Pascal Sancho wrote: Hi, Just for convenience, you should monitor the corresponding issue in Jira: https://issues.apache.org/jira/browse/FOP-1760 Bugzilla Fop issues became read-only when we migrated them to Jira. 2013/3/10 Alexey Neyman sti...@att.net Hi, Are there any plans to implement change bars in FOP? I found the bug in JIRA that claims to implement that: https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 It is in NEEDSINFO state for almost a year now, even though the author has updated the patch and (presumably) addressed the review feedback on the previous version of the patch (which is why it was switched to NEEDSINFO, as far as I understand). Is this patch going to be integrated? Regards, Alexey. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Change bars
I'm currently drawing lines with xslfo code programatically, so yes I do it with absolute positioning and it may be difficult to do if you need to print something without absolute positioning. I had started out trying to set a border on a block to draw a line and ended up drawing the block as such. fo:block-container xsl:attribute name=positionabsolute/xsl:attribute xsl:attribute name=background-colorblack/xsl:attribute xsl:attribute name=padding-top0px/xsl:attribute xsl:attribute name=padding-bottom0px/xsl:attribute xsl:attribute name=padding-left0px/xsl:attribute xsl:attribute name=padding-right0px/xsl:attribute fo:block xsl:attribute name=line-height0/xsl:attribute xsl:attribute name=linefeed-treatmentpreserve/xsl:attribute /fo:block /fo:block-container Then of course I set the left, top, width, and height attributes to tell it where to draw. -Original Message- From: Fredrik Bengtsson [mailto:fredrik.bengts...@lemontree.se] Sent: Monday, May 02, 2011 3:57 PM To: fop-users@xmlgraphics.apache.org Subject: RE: Change bars You mean absolutely positioned AT blocks, not fo:blocks? Right, I thought I'd do something like that. It'd be hard to solve at the FO level at any rate, for corner cases like tables, indented/nested blocks or variablelists. Do you mean that this is a sort of confirmation of the proposed method, that you are doing something similar? I tried just blindly adding a new attribute to my FO blocks but FOP-trunk choked on that because it did not recognize the foreign attributes. So I assume I'll have to handle them somehow specially? I seem to remember an old mail discussion that mentioned using ID attributes, maybe that is a way forward? Has anybody else experimented with having custom information fall through to the intermediate formats in general? /F -Original Message- From: Eric Douglas [mailto:edoug...@blockhouse.com] Sent: Monday, May 02, 2011 5:49 PM To: fop-users@xmlgraphics.apache.org Subject: RE: Change bars If you're just trying to draw lines you can do what I do. Currently I'm using empty block tags with border attributes. When I get around to rewriting it I want to use actual SVG line drawing commands. -Original Message- From: Fredrik Bengtsson [mailto:fredrik.bengts...@lemontree.se] Sent: Sunday, May 01, 2011 4:53 PM To: fop-users@xmlgraphics.apache.org Subject: Change bars Hey, I'm trying to make a workaround for the lack of change bar support in FOP. I was thinking about making a two-pass solution that analyzes the area tree and adds additional content where necessary. I have really modest needs so maybe that could be workable. * No nesting, only one class * Just thin simple black lines, ok if they overlap since that won't be visible * Always positioned on the exact same x-position relative to the left page margin * Just apply on entire building blocks (such as paragraphs, a title etc) However, that would need some form of tagging in the AT, that is lifted from the transform stage. That is, ideally I'd like to be able to add a myns:changed=true attribute to my input docbook blocks, and that would result in block elements in the AT that are decorated in such a way that I can pick it up. I can't just add a border-left at the fo level though, because the changed blocks might be part of a variable list or other types of elements that aren't flush with the left edge. Has anybody done something like this? Does it sound silly? Any other suggestions for workarounds? Regards, /Fredrik - 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
RE: Change bars
If you're just trying to draw lines you can do what I do. Currently I'm using empty block tags with border attributes. When I get around to rewriting it I want to use actual SVG line drawing commands. -Original Message- From: Fredrik Bengtsson [mailto:fredrik.bengts...@lemontree.se] Sent: Sunday, May 01, 2011 4:53 PM To: fop-users@xmlgraphics.apache.org Subject: Change bars Hey, I'm trying to make a workaround for the lack of change bar support in FOP. I was thinking about making a two-pass solution that analyzes the area tree and adds additional content where necessary. I have really modest needs so maybe that could be workable. * No nesting, only one class * Just thin simple black lines, ok if they overlap since that won't be visible * Always positioned on the exact same x-position relative to the left page margin * Just apply on entire building blocks (such as paragraphs, a title etc) However, that would need some form of tagging in the AT, that is lifted from the transform stage. That is, ideally I'd like to be able to add a myns:changed=true attribute to my input docbook blocks, and that would result in block elements in the AT that are decorated in such a way that I can pick it up. I can't just add a border-left at the fo level though, because the changed blocks might be part of a variable list or other types of elements that aren't flush with the left edge. Has anybody done something like this? Does it sound silly? Any other suggestions for workarounds? Regards, /Fredrik - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Change bars
You mean absolutely positioned AT blocks, not fo:blocks? Right, I thought I'd do something like that. It'd be hard to solve at the FO level at any rate, for corner cases like tables, indented/nested blocks or variablelists. Do you mean that this is a sort of confirmation of the proposed method, that you are doing something similar? I tried just blindly adding a new attribute to my FO blocks but FOP-trunk choked on that because it did not recognize the foreign attributes. So I assume I'll have to handle them somehow specially? I seem to remember an old mail discussion that mentioned using ID attributes, maybe that is a way forward? Has anybody else experimented with having custom information fall through to the intermediate formats in general? /F -Original Message- From: Eric Douglas [mailto:edoug...@blockhouse.com] Sent: Monday, May 02, 2011 5:49 PM To: fop-users@xmlgraphics.apache.org Subject: RE: Change bars If you're just trying to draw lines you can do what I do. Currently I'm using empty block tags with border attributes. When I get around to rewriting it I want to use actual SVG line drawing commands. -Original Message- From: Fredrik Bengtsson [mailto:fredrik.bengts...@lemontree.se] Sent: Sunday, May 01, 2011 4:53 PM To: fop-users@xmlgraphics.apache.org Subject: Change bars Hey, I'm trying to make a workaround for the lack of change bar support in FOP. I was thinking about making a two-pass solution that analyzes the area tree and adds additional content where necessary. I have really modest needs so maybe that could be workable. * No nesting, only one class * Just thin simple black lines, ok if they overlap since that won't be visible * Always positioned on the exact same x-position relative to the left page margin * Just apply on entire building blocks (such as paragraphs, a title etc) However, that would need some form of tagging in the AT, that is lifted from the transform stage. That is, ideally I'd like to be able to add a myns:changed=true attribute to my input docbook blocks, and that would result in block elements in the AT that are decorated in such a way that I can pick it up. I can't just add a border-left at the fo level though, because the changed blocks might be part of a variable list or other types of elements that aren't flush with the left edge. Has anybody done something like this? Does it sound silly? Any other suggestions for workarounds? Regards, /Fredrik - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Change bars
Hello, I made a patch for change-bars a while back. See Bugzilla PR 48548 https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 for a patch against /trunk from around March. May or may not apply today. As soon as I get my Linux machine to boot again, I could produce another patch against a more recent /trunk. Best regards Stephan Original-Nachricht Datum: Sun, 1 May 2011 20:52:39 + Von: Fredrik Bengtsson fredrik.bengts...@lemontree.se An: fop-users@xmlgraphics.apache.org fop-users@xmlgraphics.apache.org Betreff: Change bars Hey, I'm trying to make a workaround for the lack of change bar support in FOP. I was thinking about making a two-pass solution that analyzes the area tree and adds additional content where necessary. I have really modest needs so maybe that could be workable. * No nesting, only one class * Just thin simple black lines, ok if they overlap since that won't be visible * Always positioned on the exact same x-position relative to the left page margin * Just apply on entire building blocks (such as paragraphs, a title etc) However, that would need some form of tagging in the AT, that is lifted from the transform stage. That is, ideally I'd like to be able to add a myns:changed=true attribute to my input docbook blocks, and that would result in block elements in the AT that are decorated in such a way that I can pick it up. I can't just add a border-left at the fo level though, because the changed blocks might be part of a variable list or other types of elements that aren't flush with the left edge. Has anybody done something like this? Does it sound silly? Any other suggestions for workarounds? Regards, /Fredrik -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Change bars
Oh wow, yes that would obviously be better. Come to think of it, I've seen it mentioned but forgot. Thanks for the heads-up! I'm running a two-week-old trunk right now, but I'll consider backing up a bit for the purpose of testing that patch if it won't integrate on that. I notice in your comments that there will be gaps between lines. I'm also using line-height greater than the regular line height, I'll see if the results are visually OK. The customer is being quite picky on some aspects of the rendering. But I assume that you working on this means you have had needs and at least partial success in filling them with this implementation? Is it in any way considered to become part of the official trunk, at least to be conditionally enabled during build? I would think this is a pretty heavily requested feature, and limited support would be better than none! Thanks for your work on this. /F -Original Message- From: Stephan Thesing [mailto:thes...@gmx.de] Sent: Sunday, May 01, 2011 11:45 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Change bars Hello, I made a patch for change-bars a while back. See Bugzilla PR 48548 https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 for a patch against /trunk from around March. May or may not apply today. As soon as I get my Linux machine to boot again, I could produce another patch against a more recent /trunk. Best regards Stephan Original-Nachricht Datum: Sun, 1 May 2011 20:52:39 + Von: Fredrik Bengtsson fredrik.bengts...@lemontree.se An: fop-users@xmlgraphics.apache.org fop-users@xmlgraphics.apache.org Betreff: Change bars Hey, I'm trying to make a workaround for the lack of change bar support in FOP. I was thinking about making a two-pass solution that analyzes the area tree and adds additional content where necessary. I have really modest needs so maybe that could be workable. * No nesting, only one class * Just thin simple black lines, ok if they overlap since that won't be visible * Always positioned on the exact same x-position relative to the left page margin * Just apply on entire building blocks (such as paragraphs, a title etc) However, that would need some form of tagging in the AT, that is lifted from the transform stage. That is, ideally I'd like to be able to add a myns:changed=true attribute to my input docbook blocks, and that would result in block elements in the AT that are decorated in such a way that I can pick it up. I can't just add a border-left at the fo level though, because the changed blocks might be part of a variable list or other types of elements that aren't flush with the left edge. Has anybody done something like this? Does it sound silly? Any other suggestions for workarounds? Regards, /Fredrik -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Change bars
Despite Stephan's response, any pointers regarding a possible two-pass workaround is still valuable in case the patch proves insufficient. I noticed in the list archives that it was once mentioned that attributes not in the fo namespace are passed on to the AT or IF. Is that still correct? In that case, I might just be able to pull off the idea I mentioned in my original e-mail. I'll try it out at work during the week. /F -Original Message- From: Stephan Thesing [mailto:thes...@gmx.de] Sent: Sunday, May 01, 2011 11:45 PM To: fop-users@xmlgraphics.apache.org Subject: Re: Change bars Hello, I made a patch for change-bars a while back. See Bugzilla PR 48548 https://issues.apache.org/bugzilla/show_bug.cgi?id=48548 for a patch against /trunk from around March. May or may not apply today. As soon as I get my Linux machine to boot again, I could produce another patch against a more recent /trunk. Best regards Stephan Original-Nachricht Datum: Sun, 1 May 2011 20:52:39 + Von: Fredrik Bengtsson fredrik.bengts...@lemontree.se An: fop-users@xmlgraphics.apache.org fop-users@xmlgraphics.apache.org Betreff: Change bars Hey, I'm trying to make a workaround for the lack of change bar support in FOP. I was thinking about making a two-pass solution that analyzes the area tree and adds additional content where necessary. I have really modest needs so maybe that could be workable. * No nesting, only one class * Just thin simple black lines, ok if they overlap since that won't be visible * Always positioned on the exact same x-position relative to the left page margin * Just apply on entire building blocks (such as paragraphs, a title etc) However, that would need some form of tagging in the AT, that is lifted from the transform stage. That is, ideally I'd like to be able to add a myns:changed=true attribute to my input docbook blocks, and that would result in block elements in the AT that are decorated in such a way that I can pick it up. I can't just add a border-left at the fo level though, because the changed blocks might be part of a variable list or other types of elements that aren't flush with the left edge. Has anybody done something like this? Does it sound silly? Any other suggestions for workarounds? Regards, /Fredrik -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: RE: Change bars
And I apologize for putting the fame on Alex instead of Stephan. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Fredrik Bengtsson [mailto:fredrik.bengts...@lemontree.se] Gesendet: Montag, 4. Oktober 2010 22:28 An: fop-users@xmlgraphics.apache.org Betreff: RE: RE: Change bars I appreciate both the reply and your hard work! Thanks, I will try it out. -Original Message- From: Stephan Thesing [mailto:thes...@gmx.de] Sent: den 4 oktober 2010 19:31 To: fop-users@xmlgraphics.apache.org Subject: Re: RE: Change bars Hello, I am (still) working on the change-bars. A branch in the repository with some current code is available under branches/Temp_ChangeBars See also the bug report 48548 in Bugzilla for status and issues. Unfortunately, I have not had much time to work on this since April, but will have time available this and next month (my employer also wants to have this introduced into FOP). Best regards Stephan Thesing Original-Nachricht Datum: Mon, 4 Oct 2010 09:55:09 +0200 Von: Fredrik Bengtsson fredrik.bengts...@lemontree.se An: fop-users@xmlgraphics.apache.org Betreff: RE: Change bars Terribly sorry for the accidental Ctrl+Enter there. Continuing: Has anybody made some partially functioning patch set or similar? We have absolutely no need for styling or multiple bars; all we need is to have a simple black line whenever the revisionflag attribute is present on any docbook element spanning that vertical segment - no matter what its value or whether they are overlapping. We can even guarantee that there are no overlaps. Under these simpler circumstances, do we have a future with FOP if the solution has to be ready fairly shortly, or will we have to switch to another processor? Thanks, /Fredrik From: Fredrik Bengtsson Sent: den 4 oktober 2010 09:49 To: 'fop-users@xmlgraphics.apache.org' Subject: Change bars Hi, We are attempting to produce legal documents using FOP 1.0 for a customer. These documents, at least those that are modifications of existing regulations, make extensive use of change bars. See the attached image. I gather that there is no official support for rendering of change bars in FOP, even though there exists XSLT for producing the proper FO. What is the current state of the art here? Are there any suggestions for workarounds, or have Fredrik Bengtsson Technical Consultant Lemontree Mobile: +46 739 03 06 92 Switch: +46 8 600 41 60 Fax: +46 8 600 41 70 Email: fredrik.bengts...@lemontree.se Website: www.lemontree.se http://www.lemontree.se/ Address: Arenavägen 41, SE-121 77 Johanneshov Lemontree - skillnaden som gör skillnaden -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt freischalten! http://portal.gmx.net/de/go/maxdome - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Change bars
Terribly sorry for the accidental Ctrl+Enter there. Continuing: Has anybody made some partially functioning patch set or similar? We have absolutely no need for styling or multiple bars; all we need is to have a simple black line whenever the revisionflag attribute is present on any docbook element spanning that vertical segment - no matter what its value or whether they are overlapping. We can even guarantee that there are no overlaps. Under these simpler circumstances, do we have a future with FOP if the solution has to be ready fairly shortly, or will we have to switch to another processor? Thanks, /Fredrik From: Fredrik Bengtsson Sent: den 4 oktober 2010 09:49 To: 'fop-users@xmlgraphics.apache.org' Subject: Change bars Hi, We are attempting to produce legal documents using FOP 1.0 for a customer. These documents, at least those that are modifications of existing regulations, make extensive use of change bars. See the attached image. I gather that there is no official support for rendering of change bars in FOP, even though there exists XSLT for producing the proper FO. What is the current state of the art here? Are there any suggestions for workarounds, or have Fredrik Bengtsson Technical Consultant Lemontree Mobile: +46 739 03 06 92 Switch: +46 8 600 41 60 Fax: +46 8 600 41 70 Email: fredrik.bengts...@lemontree.se Website: www.lemontree.se http://www.lemontree.se/ Address: Arenavägen 41, SE-121 77 Johanneshov Lemontree - skillnaden som gör skillnaden
Re: RE: Change bars
Hello, I am (still) working on the change-bars. A branch in the repository with some current code is available under branches/Temp_ChangeBars See also the bug report 48548 in Bugzilla for status and issues. Unfortunately, I have not had much time to work on this since April, but will have time available this and next month (my employer also wants to have this introduced into FOP). Best regards Stephan Thesing Original-Nachricht Datum: Mon, 4 Oct 2010 09:55:09 +0200 Von: Fredrik Bengtsson fredrik.bengts...@lemontree.se An: fop-users@xmlgraphics.apache.org Betreff: RE: Change bars Terribly sorry for the accidental Ctrl+Enter there. Continuing: Has anybody made some partially functioning patch set or similar? We have absolutely no need for styling or multiple bars; all we need is to have a simple black line whenever the revisionflag attribute is present on any docbook element spanning that vertical segment - no matter what its value or whether they are overlapping. We can even guarantee that there are no overlaps. Under these simpler circumstances, do we have a future with FOP if the solution has to be ready fairly shortly, or will we have to switch to another processor? Thanks, /Fredrik From: Fredrik Bengtsson Sent: den 4 oktober 2010 09:49 To: 'fop-users@xmlgraphics.apache.org' Subject: Change bars Hi, We are attempting to produce legal documents using FOP 1.0 for a customer. These documents, at least those that are modifications of existing regulations, make extensive use of change bars. See the attached image. I gather that there is no official support for rendering of change bars in FOP, even though there exists XSLT for producing the proper FO. What is the current state of the art here? Are there any suggestions for workarounds, or have Fredrik Bengtsson Technical Consultant Lemontree Mobile: +46 739 03 06 92 Switch: +46 8 600 41 60 Fax: +46 8 600 41 70 Email: fredrik.bengts...@lemontree.se Website: www.lemontree.se http://www.lemontree.se/ Address: Arenavägen 41, SE-121 77 Johanneshov Lemontree - skillnaden som gör skillnaden -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt freischalten! http://portal.gmx.net/de/go/maxdome - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: RE: Change bars
I appreciate both the reply and your hard work! Thanks, I will try it out. -Original Message- From: Stephan Thesing [mailto:thes...@gmx.de] Sent: den 4 oktober 2010 19:31 To: fop-users@xmlgraphics.apache.org Subject: Re: RE: Change bars Hello, I am (still) working on the change-bars. A branch in the repository with some current code is available under branches/Temp_ChangeBars See also the bug report 48548 in Bugzilla for status and issues. Unfortunately, I have not had much time to work on this since April, but will have time available this and next month (my employer also wants to have this introduced into FOP). Best regards Stephan Thesing Original-Nachricht Datum: Mon, 4 Oct 2010 09:55:09 +0200 Von: Fredrik Bengtsson fredrik.bengts...@lemontree.se An: fop-users@xmlgraphics.apache.org Betreff: RE: Change bars Terribly sorry for the accidental Ctrl+Enter there. Continuing: Has anybody made some partially functioning patch set or similar? We have absolutely no need for styling or multiple bars; all we need is to have a simple black line whenever the revisionflag attribute is present on any docbook element spanning that vertical segment - no matter what its value or whether they are overlapping. We can even guarantee that there are no overlaps. Under these simpler circumstances, do we have a future with FOP if the solution has to be ready fairly shortly, or will we have to switch to another processor? Thanks, /Fredrik From: Fredrik Bengtsson Sent: den 4 oktober 2010 09:49 To: 'fop-users@xmlgraphics.apache.org' Subject: Change bars Hi, We are attempting to produce legal documents using FOP 1.0 for a customer. These documents, at least those that are modifications of existing regulations, make extensive use of change bars. See the attached image. I gather that there is no official support for rendering of change bars in FOP, even though there exists XSLT for producing the proper FO. What is the current state of the art here? Are there any suggestions for workarounds, or have Fredrik Bengtsson Technical Consultant Lemontree Mobile: +46 739 03 06 92 Switch: +46 8 600 41 60 Fax: +46 8 600 41 70 Email: fredrik.bengts...@lemontree.se Website: www.lemontree.se http://www.lemontree.se/ Address: Arenavägen 41, SE-121 77 Johanneshov Lemontree - skillnaden som gör skillnaden -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY GRATIS: Spider-Man 1-3 sowie 300 weitere Videos! Jetzt freischalten! http://portal.gmx.net/de/go/maxdome - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
