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
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 <mailto: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
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" > 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
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 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
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 > An: "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 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 > An: "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 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
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 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: Changebar Status
Here too - I am hugely interested but has to wait a couple weeks before I am let go from my current assignment to play with FOP again. Thank you for the time you have invested in this feature. -Original Message- From: Rob Sargent [mailto:rsarg...@xmission.com] Sent: den 24 maj 2011 17:10 To: fop-users@xmlgraphics.apache.org Subject: Re: Changebar Status There is interest here, but it will be a while until I can try it. Cheers, rjs On 05/23/2011 02:49 PM, Stephan Thesing wrote: > Dear all, > > has anybody tried out my patch for production of change bars in FOP yet? > > The patch against a rather recent /trunk is attached at PR 48548 ... > > I would welcome any feedback. > > Best regards > Stephan - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org