You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Fredrik Bengtsson <Fr...@lemontree.se> on 2011/05/01 22:52:39 UTC

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


RE: Change bars

Posted by Eric Douglas <ed...@blockhouse.com>.
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="position">absolute</xsl:attribute>
          <xsl:attribute name="background-color">black</xsl:attribute>
          <xsl:attribute name="padding-top">0px</xsl:attribute>
          <xsl:attribute name="padding-bottom">0px</xsl:attribute>
          <xsl:attribute name="padding-left">0px</xsl:attribute>
          <xsl:attribute name="padding-right">0px</xsl:attribute>
          <fo:block>
               <xsl:attribute name="line-height">0</xsl:attribute>
               <xsl:attribute
name="linefeed-treatment">preserve</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.Bengtsson@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:edouglas@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.Bengtsson@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Change bars

Posted by Chris Bowditch <bo...@hotmail.com>.
On 02/05/2011 20:57, Fredrik Bengtsson wrote:

Hi Fredrik,

> 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?

Yes thats right. Using the ID attribute is the way to identify what 
elements in the AT or IF XML came from which fo:blocks in the source. Up 
until recently this trick only worked in AT, but Vincent recently 
committed a change to trunk to support this in IF XML too.

> Has anybody else experimented with having custom information fall through to the intermediate formats in general?
>
> /F

Regards,

Chris

> -----Original Message-----
> From: Eric Douglas [mailto:edouglas@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.Bengtsson@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


RE: Change bars

Posted by Fredrik Bengtsson <Fr...@lemontree.se>.
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:edouglas@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.Bengtsson@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org



RE: Change bars

Posted by Eric Douglas <ed...@blockhouse.com>.
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.Bengtsson@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


RE: Change bars

Posted by Fredrik Bengtsson <Fr...@lemontree.se>.
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:thesing@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 +0000
> Von: Fredrik Bengtsson <Fr...@lemontree.se>
> An: "fop-users@xmlgraphics.apache.org" 
> <fo...@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org



RE: Change bars

Posted by Fredrik Bengtsson <Fr...@lemontree.se>.
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:thesing@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 +0000
> Von: Fredrik Bengtsson <Fr...@lemontree.se>
> An: "fop-users@xmlgraphics.apache.org" 
> <fo...@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org



Re: Change bars

Posted by Stephan Thesing <th...@gmx.de>.
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 +0000
> Von: Fredrik Bengtsson <Fr...@lemontree.se>
> An: "fop-users@xmlgraphics.apache.org" <fo...@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-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org