Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent 
Agree.  As I mentioned in my RESOVED mail, we have remove the underlying 
black which somehow seeped through in Evince and for the print shop.


Thanks for your efforts.  I think there is an issue, but whose it is is 
not clear to me and we think we're past the pain point.


Cheers,

rjs



On 11/08/2012 04:46 PM, Luis Bernardo wrote:


yes, I see the problem. it is indeed strange but I think it is the 
result of the fact that each cell is painted independently and even 
though they touch each other (the common edges of adjacent cells have 
exactly the same coordinates) the viewer (and apparently your printer) 
create an "artificial" line in between.


maybe this will need to be revisited one day... in any case, in your 
particular example you probably can get around the problem by doing 
things differently. maybe putting the background color in the side 
region instead of giving a background color to the cells of the table.


On 11/8/12 11:03 PM, Rob Sargent wrote:

Hopefully this latest one is more direct.

On 11/08/2012 04:00 PM, Glenn Adams wrote:
what i said about maximally minimizing your test FO; when you don't 
do so, you lead devs astray


On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent > wrote:


Please find attached a new fo which defines the sidebar for the
left pages only.  The blue column will show the four lines
separating each row, at least in Evince 3.4.0 (using
poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my
previous statement that I was seeing lines where they should
not be was incorrect. I think they should be there because they
are in the *fo source!

It is true that no lines appear with Adobe, but they are
visible both with Mac's Preview and Linux's Evince. But the
lines are only in the column that does not spans rows, the one
with the blue background. I do not see them in the column that
spans rows. More than that I do not see any unexpected drawing
commands in the PDF source.

Can you please explain again what lines are you seeing in the
printer output? Are they in the blue column or in the white column?

On 11/8/12 5:40 PM, Rob Sargent wrote:

We use iText as well as FOP in producing our printable
product.  Some pages get a black background from iText
(certain graphics look better that way).  When the black
background is under the sidebar (as made with the referenced
sidebar.fo ) the nuisance-some inter-cell
lines expose the black underlay. (Our fix is to not put the
black under the sidebar.)

In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't
show up in print,
BTW. To get rid of this on display, go to Acrobat's
Preferences Dialog,
select "Page Display" and enable "Enhance Thin Lines" (AR
X) or disable
"Smooth line Art". You may have to disable "Use 2D
graphics acceleration",
too. Nothing FOP can do at the moment. I've recently
explained on this
list what would need to be done to work around "Adobe's
problem".

Since there is a path whereon they do show up in print, I
wonder if this suggested work-around should be revisited? It's
not clear to me that this is still out of FOP's hands?

Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:

remove elements/attrs until the problem goes away and only
comes back when adding the element/attr just removed (no
matter what else is removed)

On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent
mailto:rsarg...@xmission.com>> wrote:

I have reviewed the sidebar.fo  and it
really cannot be substantially reduced.  It simply fills
the "outer edge" of our pages - region-start or region
end - with a narrow two-column, five-row table stretching
the length of the page.  The inner column is just spacer
and the outer column gets the section name(s) and number,
a rule and a page number.  The names are supplied in a
rotated svg (not included).










-
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org

For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Luis Bernardo 


yes, I see the problem. it is indeed strange but I think it is the 
result of the fact that each cell is painted independently and even 
though they touch each other (the common edges of adjacent cells have 
exactly the same coordinates) the viewer (and apparently your printer) 
create an "artificial" line in between.


maybe this will need to be revisited one day... in any case, in your 
particular example you probably can get around the problem by doing 
things differently. maybe putting the background color in the side 
region instead of giving a background color to the cells of the table.


On 11/8/12 11:03 PM, Rob Sargent wrote:

Hopefully this latest one is more direct.

On 11/08/2012 04:00 PM, Glenn Adams wrote:
what i said about maximally minimizing your test FO; when you don't 
do so, you lead devs astray


On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent > wrote:


Please find attached a new fo which defines the sidebar for the
left pages only.  The blue column will show the four lines
separating each row, at least in Evince 3.4.0 (using
poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my
previous statement that I was seeing lines where they should not
be was incorrect. I think they should be there because they are
in the *fo source!

It is true that no lines appear with Adobe, but they are visible
both with Mac's Preview and Linux's Evince. But the lines are
only in the column that does not spans rows, the one with the
blue background. I do not see them in the column that spans
rows. More than that I do not see any unexpected drawing
commands in the PDF source.

Can you please explain again what lines are you seeing in the
printer output? Are they in the blue column or in the white column?

On 11/8/12 5:40 PM, Rob Sargent wrote:

We use iText as well as FOP in producing our printable
product.  Some pages get a black background from iText (certain
graphics look better that way).  When the black background is
under the sidebar (as made with the referenced sidebar.fo
) the nuisance-some inter-cell lines expose
the black underlay. (Our fix is to not put the black under the
sidebar.)

In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't
show up in print,
BTW. To get rid of this on display, go to Acrobat's
Preferences Dialog,
select "Page Display" and enable "Enhance Thin Lines" (AR
X) or disable
"Smooth line Art". You may have to disable "Use 2D graphics
acceleration",
too. Nothing FOP can do at the moment. I've recently
explained on this
list what would need to be done to work around "Adobe's
problem".

Since there is a path whereon they do show up in print, I
wonder if this suggested work-around should be revisited? It's
not clear to me that this is still out of FOP's hands?

Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:

remove elements/attrs until the problem goes away and only
comes back when adding the element/attr just removed (no
matter what else is removed)

On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent
mailto:rsarg...@xmission.com>> wrote:

I have reviewed the sidebar.fo  and it
really cannot be substantially reduced. It simply fills
the "outer edge" of our pages - region-start or region end
- with a narrow two-column, five-row table stretching the
length of the page.  The inner column is just spacer and
the outer column gets the section name(s) and number, a
rule and a page number. The names are supplied in a
rotated svg (not included).










-
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org

For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent 

Hopefully this latest one is more direct.

On 11/08/2012 04:00 PM, Glenn Adams wrote:
what i said about maximally minimizing your test FO; when you don't do 
so, you lead devs astray


On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent > wrote:


Please find attached a new fo which defines the sidebar for the
left pages only.  The blue column will show the four lines
separating each row, at least in Evince 3.4.0 (using
poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my
previous statement that I was seeing lines where they should not
be was incorrect. I think they should be there because they are
in the *fo source!

It is true that no lines appear with Adobe, but they are visible
both with Mac's Preview and Linux's Evince. But the lines are
only in the column that does not spans rows, the one with the
blue background. I do not see them in the column that spans rows.
More than that I do not see any unexpected drawing commands in
the PDF source.

Can you please explain again what lines are you seeing in the
printer output? Are they in the blue column or in the white column?

On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product. 
Some pages get a black background from iText (certain graphics

look better that way).  When the black background is under the
sidebar (as made with the referenced sidebar.fo
) the nuisance-some inter-cell lines expose
the black underlay. (Our fix is to not put the black under the
sidebar.)

In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show
up in print,
BTW. To get rid of this on display, go to Acrobat's
Preferences Dialog,
select "Page Display" and enable "Enhance Thin Lines" (AR X)
or disable
"Smooth line Art". You may have to disable "Use 2D graphics
acceleration",
too. Nothing FOP can do at the moment. I've recently
explained on this
list what would need to be done to work around "Adobe's
problem".

Since there is a path whereon they do show up in print, I wonder
if this suggested work-around should be revisited? It's not
clear to me that this is still out of FOP's hands?

Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:

remove elements/attrs until the problem goes away and only
comes back when adding the element/attr just removed (no matter
what else is removed)

On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent
mailto:rsarg...@xmission.com>> wrote:

I have reviewed the sidebar.fo  and it
really cannot be substantially reduced.  It simply fills
the "outer edge" of our pages - region-start or region end
- with a narrow two-column, five-row table stretching the
length of the page.  The inner column is just spacer and
the outer column gets the section name(s) and number, a
rule and a page number.  The names are supplied in a
rotated svg (not included).










-
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org

For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Glenn Adams 
what i said about maximally minimizing your test FO; when you don't do so,
you lead devs astray

On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent  wrote:

>  Please find attached a new fo which defines the sidebar for the left
> pages only.  The blue column will show the four lines separating each row,
> at least in Evince 3.4.0 (using poppler/cairo(0.18.4))
>
>
> On 11/08/2012 03:19 PM, Luis Bernardo wrote:
>
>
> Rob, I looked with more time at this issue and I think that my previous
> statement that I was seeing lines where they should not be was incorrect. I
> think they should be there because they are in the *fo source!
>
> It is true that no lines appear with Adobe, but they are visible both with
> Mac's Preview and Linux's Evince. But the lines are only in the column that
> does not spans rows, the one with the blue background. I do not see them in
> the column that spans rows. More than that I do not see any unexpected
> drawing commands in the PDF source.
>
> Can you please explain again what lines are you seeing in the printer
> output? Are they in the blue column or in the white column?
>
> On 11/8/12 5:40 PM, Rob Sargent wrote:
>
> We use iText as well as FOP in producing our printable product.  Some
> pages get a black background from iText (certain graphics look better that
> way).  When the black background is under the sidebar (as made with the
> referenced sidebar.fo) the nuisance-some inter-cell lines expose the
> black underlay. (Our fix is to not put the black under the sidebar.)
>
> In the original thread Jeremias Maerki wrote
>
> I suspect it's once
> more Adobe's anti-aliasing to be blamed. And this won't show up in print,
> BTW. To get rid of this on display, go to Acrobat's Preferences Dialog,
> select "Page Display" and enable "Enhance Thin Lines" (AR X) or disable
> "Smooth line Art". You may have to disable "Use 2D graphics acceleration",
> too. Nothing FOP can do at the moment. I've recently explained on this
> list what would need to be done to work around "Adobe's problem".
>
> Since there is a path whereon they do show up in print, I wonder if this
> suggested work-around should be revisited? It's not clear to me that this
> is still out of FOP's hands?
>
> Thank you for your indulgence,
>
> rjs
>
>
> On 11/05/2012 05:10 PM, Glenn Adams wrote:
>
> remove elements/attrs until the problem goes away and only comes back when
> adding the element/attr just removed (no matter what else is removed)
>
> On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent  wrote:
>
>>  I have reviewed the sidebar.fo and it really cannot be substantially
>> reduced.  It simply fills the "outer edge" of our pages - region-start or
>> region end - with a narrow two-column, five-row table stretching the length
>> of the page.  The inner column is just spacer and the outer column gets the
>> section name(s) and number, a rule and a page number.  The names are
>> supplied in a rotated svg (not included).
>>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
>

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent 
Please find attached a new fo which defines the sidebar for the left 
pages only.  The blue column will show the four lines separating each 
row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my 
previous statement that I was seeing lines where they should not be 
was incorrect. I think they should be there because they are in the 
*fo source!


It is true that no lines appear with Adobe, but they are visible both 
with Mac's Preview and Linux's Evince. But the lines are only in the 
column that does not spans rows, the one with the blue background. I 
do not see them in the column that spans rows. More than that I do not 
see any unexpected drawing commands in the PDF source.


Can you please explain again what lines are you seeing in the printer 
output? Are they in the blue column or in the white column?


On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way).  When the black background is under the sidebar (as made 
with the referenced sidebar.fo) the nuisance-some inter-cell lines 
expose the black underlay. (Our fix is to not put the black under the 
sidebar.)


In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show up
in print,
BTW. To get rid of this on display, go to Acrobat's Preferences
Dialog,
select "Page Display" and enable "Enhance Thin Lines" (AR X) or
disable
"Smooth line Art". You may have to disable "Use 2D graphics
acceleration",
too. Nothing FOP can do at the moment. I've recently explained on
this
list what would need to be done to work around "Adobe's problem".

Since there is a path whereon they do show up in print, I wonder if 
this suggested work-around should be revisited? It's not clear to me 
that this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes 
back when adding the element/attr just removed (no matter what else 
is removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent > wrote:


I have reviewed the sidebar.fo  and it really
cannot be substantially reduced.  It simply fills the "outer
edge" of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page. 
The inner column is just spacer and the outer column gets the

section name(s) and number, a rule and a page number.  The names
are supplied in a rotated svg (not included).









http://www.w3.org/1999/XSL/Format"; xmlns:xalan="http://xml.apache.org/xslt"; xmlns:ec="xalan://com.amirsys.utilities.ElementConversion">
  

  


  


  
  


  
  

  
  

  



  

  

  


  

  
  

   

  
  

   

  
  

   

  
  

  

  

  

  


  
  

  





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

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent 
When I reviewed sidebar.fo, I completely neglected the colours and 
borders added for debug purposes (oh so long ago). Let me get you a 
clean version.  The "spurious lines" appear in the column which is not 
spanned by the "inner" cell in the first row.




On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my 
previous statement that I was seeing lines where they should not be 
was incorrect. I think they should be there because they are in the 
*fo source!


It is true that no lines appear with Adobe, but they are visible both 
with Mac's Preview and Linux's Evince. But the lines are only in the 
column that does not spans rows, the one with the blue background. I 
do not see them in the column that spans rows. More than that I do not 
see any unexpected drawing commands in the PDF source.


Can you please explain again what lines are you seeing in the printer 
output? Are they in the blue column or in the white column?


On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way).  When the black background is under the sidebar (as made 
with the referenced sidebar.fo) the nuisance-some inter-cell lines 
expose the black underlay. (Our fix is to not put the black under the 
sidebar.)


In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show up
in print,
BTW. To get rid of this on display, go to Acrobat's Preferences
Dialog,
select "Page Display" and enable "Enhance Thin Lines" (AR X) or
disable
"Smooth line Art". You may have to disable "Use 2D graphics
acceleration",
too. Nothing FOP can do at the moment. I've recently explained on
this
list what would need to be done to work around "Adobe's problem".

Since there is a path whereon they do show up in print, I wonder if 
this suggested work-around should be revisited? It's not clear to me 
that this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes 
back when adding the element/attr just removed (no matter what else 
is removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent > wrote:


I have reviewed the sidebar.fo  and it really
cannot be substantially reduced.  It simply fills the "outer
edge" of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page. 
The inner column is just spacer and the outer column gets the

section name(s) and number, a rule and a page number.  The names
are supplied in a rotated svg (not included).

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Luis Bernardo 


Rob, I looked with more time at this issue and I think that my previous 
statement that I was seeing lines where they should not be was 
incorrect. I think they should be there because they are in the *fo source!


It is true that no lines appear with Adobe, but they are visible both 
with Mac's Preview and Linux's Evince. But the lines are only in the 
column that does not spans rows, the one with the blue background. I do 
not see them in the column that spans rows. More than that I do not see 
any unexpected drawing commands in the PDF source.


Can you please explain again what lines are you seeing in the printer 
output? Are they in the blue column or in the white column?


On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way).  When the black background is under the sidebar (as made 
with the referenced sidebar.fo) the nuisance-some inter-cell lines 
expose the black underlay. (Our fix is to not put the black under the 
sidebar.)


In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show up in
print,
BTW. To get rid of this on display, go to Acrobat's Preferences
Dialog,
select "Page Display" and enable "Enhance Thin Lines" (AR X) or
disable
"Smooth line Art". You may have to disable "Use 2D graphics
acceleration",
too. Nothing FOP can do at the moment. I've recently explained on
this
list what would need to be done to work around "Adobe's problem".

Since there is a path whereon they do show up in print, I wonder if 
this suggested work-around should be revisited? It's not clear to me 
that this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes back 
when adding the element/attr just removed (no matter what else is 
removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent > wrote:


I have reviewed the sidebar.fo  and it really
cannot be substantially reduced.  It simply fills the "outer
edge" of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page. 
The inner column is just spacer and the outer column gets the

section name(s) and number, a rule and a page number.  The names
are supplied in a rotated svg (not included).

Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent 
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way). When the black background is under the sidebar (as made with 
the referenced sidebar.fo) the nuisance-some inter-cell lines expose the 
black underlay. (Our fix is to not put the black under the sidebar.)


In the original thread Jeremias Maerki wrote

   I suspect it's once
   more Adobe's anti-aliasing to be blamed. And this won't show up in
   print,
   BTW. To get rid of this on display, go to Acrobat's Preferences Dialog,
   select "Page Display" and enable "Enhance Thin Lines" (AR X) or disable
   "Smooth line Art". You may have to disable "Use 2D graphics
   acceleration",
   too. Nothing FOP can do at the moment. I've recently explained on this
   list what would need to be done to work around "Adobe's problem".

Since there is a path whereon they do show up in print, I wonder if this 
suggested work-around should be revisited? It's not clear to me that 
this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes back 
when adding the element/attr just removed (no matter what else is removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent > wrote:


I have reviewed the sidebar.fo  and it really
cannot be substantially reduced.  It simply fills the "outer edge"
of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page.  The
inner column is just spacer and the outer column gets the section
name(s) and number, a rule and a page number.  The names are
supplied in a rotated svg (not included).