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 Rob Sargent <rs...@xmission.com> on 2012/11/08 18:40:12 UTC
Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
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 <rsargent@xmission.com
> <ma...@xmission.com>> wrote:
>
> I have reviewed the sidebar.fo <http://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
Posted by Rob Sargent <rs...@xmission.com>.
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 <rsargent@xmission.com
>>> <ma...@xmission.com>> wrote:
>>>
>>> I have reviewed the sidebar.fo <http://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
Posted by Rob Sargent <rs...@xmission.com>.
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 <rsargent@xmission.com
>>> <ma...@xmission.com>> 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 <http://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
>>>>>> <rsargent@xmission.com <ma...@xmission.com>> wrote:
>>>>>>
>>>>>> I have reviewed the sidebar.fo <http://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-unsubscribe@xmlgraphics.apache.org
>>> <ma...@xmlgraphics.apache.org>
>>> For additional commands, e-mail:
>>> fop-users-help@xmlgraphics.apache.org
>>> <ma...@xmlgraphics.apache.org>
>>>
>>>
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
Posted by Luis Bernardo <lm...@gmail.com>.
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 <rsargent@xmission.com
>> <ma...@xmission.com>> 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
>>>> <http://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
>>>>> <rsargent@xmission.com <ma...@xmission.com>> wrote:
>>>>>
>>>>> I have reviewed the sidebar.fo <http://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-unsubscribe@xmlgraphics.apache.org
>> <ma...@xmlgraphics.apache.org>
>> For additional commands, e-mail:
>> fop-users-help@xmlgraphics.apache.org
>> <ma...@xmlgraphics.apache.org>
>>
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
Posted by Rob Sargent <rs...@xmission.com>.
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 <rsargent@xmission.com
> <ma...@xmission.com>> 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
>>> <http://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
>>>> <rsargent@xmission.com <ma...@xmission.com>> wrote:
>>>>
>>>> I have reviewed the sidebar.fo <http://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-unsubscribe@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
> For additional commands, e-mail:
> fop-users-help@xmlgraphics.apache.org
> <ma...@xmlgraphics.apache.org>
>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
Posted by Glenn Adams <gl...@skynav.com>.
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 <rs...@xmission.com> 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 <rs...@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-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
Posted by Rob Sargent <rs...@xmission.com>.
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 <rsargent@xmission.com
>>> <ma...@xmission.com>> wrote:
>>>
>>> I have reviewed the sidebar.fo <http://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
Posted by Luis Bernardo <lm...@gmail.com>.
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 <rsargent@xmission.com
>> <ma...@xmission.com>> wrote:
>>
>> I have reviewed the sidebar.fo <http://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).
>>
>>
>