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
Inclusing of a dynmaically generated SVG into XSL
Hi,
I have a dynamically generated SVG image (using Batik included with the FOP
distribution) and I want to pass the SVG (say as a bytearrayoutputstream) into
the render process. The render process is typical:
bufferedOutputStream = new BufferedOutputStream( new FileOutputStream(
outputPDFFile ) );
fop = fopFactory.newFop( org.apache.xmlgraphics.util.MimeConstants.MIME_PDF,
foUserAgent, bufferedOutputStream );
transformer = TransformerFactory.newInstance().newTransformer( new
StreamSource( xslStylesheet ) );
source = new StreamSource( xmlData );
result = new SAXResult( fop.getDefaultHandler() );
transformer.transform( source, result );
I've found the following two articles which have given me a bit of an idea:
http://old.nabble.com/How-to-transform-embedded-FO--td31231565.html
http://old.nabble.com/Embedding-SVG-dynamically-into-fo-file-td30691616.html
but I can't seem to figure out once I have my SVG as a bytearraystream what to
do with it:
SAXSource saxSource = new SAXSource( new InputSource( new ByteArrayInputStream(
byteArrayOutputStream.toByteArray() ) ) );
Where do I put the saxSource?
At the other end, what tag/block do I use in the XSL file to place the SVG?
Currently I pull in an SVG file using the tag
fo:block background-image=url('background.svg') background-repeat=repeat
background-position-horizontal=center background-position-vertical=center
which is fine for the file version...but not sure what to do for a dynamically
generated version.
From what I've read it should be possible to create an SVG on the fly and pass
it into the render process...just can't join all the dots!
Thanks in advance,
Bernard.
