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/05 18:28:51 UTC
Inter-cell lines no longer "spurious" pdf viewer problem?
In January 2011, I asked about the spurious lines between rows of tables
(here
<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the lines are showing up
on the pages from the print shop, but not our not local (low-res)
printers. Is this another silent change in fop-1.1 pdf generataion?
rjs
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).
>>
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
Posted by Rob Sargent <rs...@xmission.com>.
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?
Posted by Glenn Adams <gl...@skynav.com>.
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).
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Rob Sargent <rs...@xmission.com>.
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).
On 11/05/2012 04:32 PM, Rob Sargent wrote:
> Thank you Luis
>
> I may have to embed a table within a table as you suggest. Or perhaps
> I can play with "layers" and z-values. Any other hints appreciated.
>
> rjs
>
> On 11/05/2012 04:09 PM, Luis Bernardo wrote:
>>
>> I assume you refer to the sidebar.fo sample.
>>
>> As you said, the lines are not visible in Adobe. They are visible in
>> Mac's own Preview though. I looked at the *.fo and although I don't
>> understand what you are trying to achieve I do see that the output in
>> Preview is not what I would expect. Can you provide a smaller
>> example? Meanwhile, if you have a problem in hands with unexpected
>> lines due to the use of row or column spans try to get around it by
>> nesting tables.
>>
>> On 11/5/12 7:41 PM, Rob Sargent wrote:
>>>
>>> Correction: the referenced previous post did include an fo of the
>>> table in question.
>>>
>>> rjs
>>>
>>> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>>>>
>>>> Glenn,
>>>>
>>>> My apologies for not including relevant fo etc but the original
>>>> post I referenced didn't need them, explained the situation well
>>>> enough for at least one available savant and I am only asking if
>>>> there is (another) silent change in the pdf output irrespective of
>>>> any fo input. (The other silent change being the in-stream
>>>> description of rgb colors.)
>>>>
>>>> rjs
>>>>
>>>> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>>>>> Rob, I'm sure you realize nobody can respond to such a query
>>>>> unless they can read your mind to learn the input you used and the
>>>>> output you are seeing. Since such skills are hard to come by, I'd
>>>>> suggest you *always* provide sample input and output files when
>>>>> asking such a question. We devs are very few in number and you
>>>>> absolutely *must* do everything possible to help us determine the
>>>>> source of a problem. There is a well defined process here: submit
>>>>> a bug report with a reduced (maximally minimal) input file and an
>>>>> output file. Absent this, don't expect any response.
>>>>>
>>>>> G.
>>>>>
>>>>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rsargent@xmission.com
>>>>> <ma...@xmission.com>> wrote:
>>>>>
>>>>> In January 2011, I asked about the spurious lines between rows
>>>>> of tables (here
>>>>> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>>>>> and that was all on fop-1.0. Now on fop-1.1 and the lines are
>>>>> showing up on the pages from the print shop, but not our not
>>>>> local (low-res) printers. Is this another silent change in
>>>>> fop-1.1 pdf generataion?
>>>>>
>>>>
>>>
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Rob Sargent <rs...@xmission.com>.
Thank you Luis
I may have to embed a table within a table as you suggest. Or perhaps I
can play with "layers" and z-values. Any other hints appreciated.
rjs
On 11/05/2012 04:09 PM, Luis Bernardo wrote:
>
> I assume you refer to the sidebar.fo sample.
>
> As you said, the lines are not visible in Adobe. They are visible in
> Mac's own Preview though. I looked at the *.fo and although I don't
> understand what you are trying to achieve I do see that the output in
> Preview is not what I would expect. Can you provide a smaller example?
> Meanwhile, if you have a problem in hands with unexpected lines due to
> the use of row or column spans try to get around it by nesting tables.
>
> On 11/5/12 7:41 PM, Rob Sargent wrote:
>>
>> Correction: the referenced previous post did include an fo of the
>> table in question.
>>
>> rjs
>>
>> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>>>
>>> Glenn,
>>>
>>> My apologies for not including relevant fo etc but the original post
>>> I referenced didn't need them, explained the situation well enough
>>> for at least one available savant and I am only asking if there is
>>> (another) silent change in the pdf output irrespective of any fo
>>> input. (The other silent change being the in-stream description of
>>> rgb colors.)
>>>
>>> rjs
>>>
>>> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>>>> Rob, I'm sure you realize nobody can respond to such a query unless
>>>> they can read your mind to learn the input you used and the output
>>>> you are seeing. Since such skills are hard to come by, I'd suggest
>>>> you *always* provide sample input and output files when asking such
>>>> a question. We devs are very few in number and you absolutely
>>>> *must* do everything possible to help us determine the source of a
>>>> problem. There is a well defined process here: submit a bug report
>>>> with a reduced (maximally minimal) input file and an output file.
>>>> Absent this, don't expect any response.
>>>>
>>>> G.
>>>>
>>>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rsargent@xmission.com
>>>> <ma...@xmission.com>> wrote:
>>>>
>>>> In January 2011, I asked about the spurious lines between rows
>>>> of tables (here
>>>> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>>>> and that was all on fop-1.0. Now on fop-1.1 and the lines are
>>>> showing up on the pages from the print shop, but not our not
>>>> local (low-res) printers. Is this another silent change in
>>>> fop-1.1 pdf generataion?
>>>>
>>>
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Luis Bernardo <lm...@gmail.com>.
I assume you refer to the sidebar.fo sample.
As you said, the lines are not visible in Adobe. They are visible in
Mac's own Preview though. I looked at the *.fo and although I don't
understand what you are trying to achieve I do see that the output in
Preview is not what I would expect. Can you provide a smaller example?
Meanwhile, if you have a problem in hands with unexpected lines due to
the use of row or column spans try to get around it by nesting tables.
On 11/5/12 7:41 PM, Rob Sargent wrote:
>
> Correction: the referenced previous post did include an fo of the
> table in question.
>
> rjs
>
> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>>
>> Glenn,
>>
>> My apologies for not including relevant fo etc but the original post
>> I referenced didn't need them, explained the situation well enough
>> for at least one available savant and I am only asking if there is
>> (another) silent change in the pdf output irrespective of any fo
>> input. (The other silent change being the in-stream description of
>> rgb colors.)
>>
>> rjs
>>
>> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>>> Rob, I'm sure you realize nobody can respond to such a query unless
>>> they can read your mind to learn the input you used and the output
>>> you are seeing. Since such skills are hard to come by, I'd suggest
>>> you *always* provide sample input and output files when asking such
>>> a question. We devs are very few in number and you absolutely *must*
>>> do everything possible to help us determine the source of a problem.
>>> There is a well defined process here: submit a bug report with a
>>> reduced (maximally minimal) input file and an output file. Absent
>>> this, don't expect any response.
>>>
>>> G.
>>>
>>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rsargent@xmission.com
>>> <ma...@xmission.com>> wrote:
>>>
>>> In January 2011, I asked about the spurious lines between rows
>>> of tables (here
>>> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>>> and that was all on fop-1.0. Now on fop-1.1 and the lines are
>>> showing up on the pages from the print shop, but not our not
>>> local (low-res) printers. Is this another silent change in
>>> fop-1.1 pdf generataion?
>>>
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Rob Sargent <rs...@xmission.com>.
As you saw in the referenced original thread, the problem was in the
viewer (Evince in particular). Now it appears that some (only the outter
edge) of the spurious lines have made it to the printed page, where as
before the did not. There is an fo producing the table in question
however our ultimate produce gets additional bleed colouration prior to
production printing. I'm just hoping this rings a bell for another
user, or someone familiar with the end game of printing from pdf.
rjs
On 11/05/2012 03:15 PM, Glenn Adams wrote:
> As you point out, this is a problem you saw with 1.0 and now see with
> 1.1, so it isn't a first communique. In any case, I'd rather have a
> bug report with test input/output files to evaluate. It's easier to
> close a non-bug than to evaluate a query that is absent the necessary
> data to properly evaluate it.
>
> Clearly, strict usage questions should come to this list first, but
> you aren't asking a usage question.
>
> On Tue, Nov 6, 2012 at 6:10 AM, Rob Sargent <rsargent@xmission.com
> <ma...@xmission.com>> wrote:
>
> I have no intention of circumventing normal processes, though I'm
> surprised that your recommended first communique is to submit a
> bug rather than pose a question. Is this the general consensus?
>
> I don't know if there is a bug - there wasn't a year ago. Some
> behaviour seems to have changed since Feb. 2011 - it could be the
> print-shop. I'm just asking if anyone on the list, including but
> not limited to the developers, has any insight into the matter.
>
> rjs
>
>
>
>
> On 11/05/2012 01:34 PM, Glenn Adams wrote:
>> file a bug and attach the files if you wish a dev to evaluate;
>> personally, i ignore requests on fop-users that attempt to
>> circumvent the normal bug reporting process
>>
>> On Tue, Nov 6, 2012 at 3:41 AM, Rob Sargent
>> <rsargent@xmission.com <ma...@xmission.com>> wrote:
>>
>>
>> Correction: the referenced previous post did include an fo
>> of the table in question.
>>
>> rjs
>>
>>
>> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>>>
>>> Glenn,
>>>
>>> My apologies for not including relevant fo etc but the
>>> original post I referenced didn't need them, explained the
>>> situation well enough for at least one available savant and
>>> I am only asking if there is (another) silent change in the
>>> pdf output irrespective of any fo input. (The other silent
>>> change being the in-stream description of rgb colors.)
>>>
>>> rjs
>>>
>>> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>>>> Rob, I'm sure you realize nobody can respond to such a
>>>> query unless they can read your mind to learn the input you
>>>> used and the output you are seeing. Since such skills are
>>>> hard to come by, I'd suggest you *always* provide sample
>>>> input and output files when asking such a question. We devs
>>>> are very few in number and you absolutely *must* do
>>>> everything possible to help us determine the source of a
>>>> problem. There is a well defined process here: submit a bug
>>>> report with a reduced (maximally minimal) input file and an
>>>> output file. Absent this, don't expect any response.
>>>>
>>>> G.
>>>>
>>>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent
>>>> <rsargent@xmission.com <ma...@xmission.com>> wrote:
>>>>
>>>> In January 2011, I asked about the spurious lines
>>>> between rows of tables (here
>>>> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>>>> and that was all on fop-1.0. Now on fop-1.1 and the
>>>> lines are showing up on the pages from the print shop,
>>>> but not our not local (low-res) printers. Is this
>>>> another silent change in fop-1.1 pdf generataion?
>>>>
>>>
>>
>>
>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Glenn Adams <gl...@skynav.com>.
As you point out, this is a problem you saw with 1.0 and now see with 1.1,
so it isn't a first communique. In any case, I'd rather have a bug report
with test input/output files to evaluate. It's easier to close a non-bug
than to evaluate a query that is absent the necessary data to properly
evaluate it.
Clearly, strict usage questions should come to this list first, but you
aren't asking a usage question.
On Tue, Nov 6, 2012 at 6:10 AM, Rob Sargent <rs...@xmission.com> wrote:
> I have no intention of circumventing normal processes, though I'm
> surprised that your recommended first communique is to submit a bug rather
> than pose a question. Is this the general consensus?
>
> I don't know if there is a bug - there wasn't a year ago. Some behaviour
> seems to have changed since Feb. 2011 - it could be the print-shop. I'm
> just asking if anyone on the list, including but not limited to the
> developers, has any insight into the matter.
>
> rjs
>
>
>
>
> On 11/05/2012 01:34 PM, Glenn Adams wrote:
>
> file a bug and attach the files if you wish a dev to evaluate; personally,
> i ignore requests on fop-users that attempt to circumvent the normal bug
> reporting process
>
> On Tue, Nov 6, 2012 at 3:41 AM, Rob Sargent <rs...@xmission.com> wrote:
>
>>
>> Correction: the referenced previous post did include an fo of the table
>> in question.
>>
>> rjs
>>
>>
>> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>>
>>
>> Glenn,
>>
>> My apologies for not including relevant fo etc but the original post I
>> referenced didn't need them, explained the situation well enough for at
>> least one available savant and I am only asking if there is (another)
>> silent change in the pdf output irrespective of any fo input. (The other
>> silent change being the in-stream description of rgb colors.)
>>
>> rjs
>>
>> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>>
>> Rob, I'm sure you realize nobody can respond to such a query unless they
>> can read your mind to learn the input you used and the output you are
>> seeing. Since such skills are hard to come by, I'd suggest you *always*
>> provide sample input and output files when asking such a question. We devs
>> are very few in number and you absolutely *must* do everything possible to
>> help us determine the source of a problem. There is a well defined process
>> here: submit a bug report with a reduced (maximally minimal) input file and
>> an output file. Absent this, don't expect any response.
>>
>> G.
>>
>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rs...@xmission.com>wrote:
>>
>>> In January 2011, I asked about the spurious lines between rows of
>>> tables (here<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>>> and that was all on fop-1.0. Now on fop-1.1 and the lines are showing up on
>>> the pages from the print shop, but not our not local (low-res) printers.
>>> Is this another silent change in fop-1.1 pdf generataion?
>>>
>>
>>
>>
>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Rob Sargent <rs...@xmission.com>.
I have no intention of circumventing normal processes, though I'm
surprised that your recommended first communique is to submit a bug
rather than pose a question. Is this the general consensus?
I don't know if there is a bug - there wasn't a year ago. Some
behaviour seems to have changed since Feb. 2011 - it could be the
print-shop. I'm just asking if anyone on the list, including but not
limited to the developers, has any insight into the matter.
rjs
On 11/05/2012 01:34 PM, Glenn Adams wrote:
> file a bug and attach the files if you wish a dev to evaluate;
> personally, i ignore requests on fop-users that attempt to circumvent
> the normal bug reporting process
>
> On Tue, Nov 6, 2012 at 3:41 AM, Rob Sargent <rsargent@xmission.com
> <ma...@xmission.com>> wrote:
>
>
> Correction: the referenced previous post did include an fo of the
> table in question.
>
> rjs
>
>
> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>>
>> Glenn,
>>
>> My apologies for not including relevant fo etc but the original
>> post I referenced didn't need them, explained the situation well
>> enough for at least one available savant and I am only asking if
>> there is (another) silent change in the pdf output irrespective
>> of any fo input. (The other silent change being the in-stream
>> description of rgb colors.)
>>
>> rjs
>>
>> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>>> Rob, I'm sure you realize nobody can respond to such a query
>>> unless they can read your mind to learn the input you used and
>>> the output you are seeing. Since such skills are hard to come
>>> by, I'd suggest you *always* provide sample input and output
>>> files when asking such a question. We devs are very few in
>>> number and you absolutely *must* do everything possible to help
>>> us determine the source of a problem. There is a well defined
>>> process here: submit a bug report with a reduced (maximally
>>> minimal) input file and an output file. Absent this, don't
>>> expect any response.
>>>
>>> G.
>>>
>>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent
>>> <rsargent@xmission.com <ma...@xmission.com>> wrote:
>>>
>>> In January 2011, I asked about the spurious lines between
>>> rows of tables (here
>>> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>>> and that was all on fop-1.0. Now on fop-1.1 and the lines
>>> are showing up on the pages from the print shop, but not our
>>> not local (low-res) printers. Is this another silent change
>>> in fop-1.1 pdf generataion?
>>>
>>
>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Glenn Adams <gl...@skynav.com>.
file a bug and attach the files if you wish a dev to evaluate; personally,
i ignore requests on fop-users that attempt to circumvent the normal bug
reporting process
On Tue, Nov 6, 2012 at 3:41 AM, Rob Sargent <rs...@xmission.com> wrote:
>
> Correction: the referenced previous post did include an fo of the table
> in question.
>
> rjs
>
>
> On 11/05/2012 12:38 PM, Rob Sargent wrote:
>
>
> Glenn,
>
> My apologies for not including relevant fo etc but the original post I
> referenced didn't need them, explained the situation well enough for at
> least one available savant and I am only asking if there is (another)
> silent change in the pdf output irrespective of any fo input. (The other
> silent change being the in-stream description of rgb colors.)
>
> rjs
>
> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>
> Rob, I'm sure you realize nobody can respond to such a query unless they
> can read your mind to learn the input you used and the output you are
> seeing. Since such skills are hard to come by, I'd suggest you *always*
> provide sample input and output files when asking such a question. We devs
> are very few in number and you absolutely *must* do everything possible to
> help us determine the source of a problem. There is a well defined process
> here: submit a bug report with a reduced (maximally minimal) input file and
> an output file. Absent this, don't expect any response.
>
> G.
>
> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rs...@xmission.com> wrote:
>
>> In January 2011, I asked about the spurious lines between rows of
>> tables (here<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>> and that was all on fop-1.0. Now on fop-1.1 and the lines are showing up on
>> the pages from the print shop, but not our not local (low-res) printers.
>> Is this another silent change in fop-1.1 pdf generataion?
>>
>
>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Rob Sargent <rs...@xmission.com>.
Correction: the referenced previous post did include an fo of the table
in question.
rjs
On 11/05/2012 12:38 PM, Rob Sargent wrote:
>
> Glenn,
>
> My apologies for not including relevant fo etc but the original post I
> referenced didn't need them, explained the situation well enough for
> at least one available savant and I am only asking if there is
> (another) silent change in the pdf output irrespective of any fo
> input. (The other silent change being the in-stream description of
> rgb colors.)
>
> rjs
>
> On 11/05/2012 10:58 AM, Glenn Adams wrote:
>> Rob, I'm sure you realize nobody can respond to such a query unless
>> they can read your mind to learn the input you used and the output
>> you are seeing. Since such skills are hard to come by, I'd suggest
>> you *always* provide sample input and output files when asking such a
>> question. We devs are very few in number and you absolutely *must* do
>> everything possible to help us determine the source of a problem.
>> There is a well defined process here: submit a bug report with a
>> reduced (maximally minimal) input file and an output file. Absent
>> this, don't expect any response.
>>
>> G.
>>
>> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rsargent@xmission.com
>> <ma...@xmission.com>> wrote:
>>
>> In January 2011, I asked about the spurious lines between rows of
>> tables (here
>> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
>> and that was all on fop-1.0. Now on fop-1.1 and the lines are
>> showing up on the pages from the print shop, but not our not
>> local (low-res) printers. Is this another silent change in
>> fop-1.1 pdf generataion?
>>
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Rob Sargent <rs...@xmission.com>.
Glenn,
My apologies for not including relevant fo etc but the original post I
referenced didn't need them, explained the situation well enough for at
least one available savant and I am only asking if there is (another)
silent change in the pdf output irrespective of any fo input. (The
other silent change being the in-stream description of rgb colors.)
rjs
On 11/05/2012 10:58 AM, Glenn Adams wrote:
> Rob, I'm sure you realize nobody can respond to such a query unless
> they can read your mind to learn the input you used and the output you
> are seeing. Since such skills are hard to come by, I'd suggest you
> *always* provide sample input and output files when asking such a
> question. We devs are very few in number and you absolutely *must* do
> everything possible to help us determine the source of a problem.
> There is a well defined process here: submit a bug report with a
> reduced (maximally minimal) input file and an output file. Absent
> this, don't expect any response.
>
> G.
>
> On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rsargent@xmission.com
> <ma...@xmission.com>> wrote:
>
> In January 2011, I asked about the spurious lines between rows of
> tables (here
> <http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
> and that was all on fop-1.0. Now on fop-1.1 and the lines are
> showing up on the pages from the print shop, but not our not local
> (low-res) printers. Is this another silent change in fop-1.1 pdf
> generataion?
>
Re: Inter-cell lines no longer "spurious" pdf viewer problem?
Posted by Glenn Adams <gl...@skynav.com>.
Rob, I'm sure you realize nobody can respond to such a query unless they
can read your mind to learn the input you used and the output you are
seeing. Since such skills are hard to come by, I'd suggest you *always*
provide sample input and output files when asking such a question. We devs
are very few in number and you absolutely *must* do everything possible to
help us determine the source of a problem. There is a well defined process
here: submit a bug report with a reduced (maximally minimal) input file and
an output file. Absent this, don't expect any response.
G.
On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <rs...@xmission.com> wrote:
> In January 2011, I asked about the spurious lines between rows of tables
> (here<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
> and that was all on fop-1.0. Now on fop-1.1 and the lines are showing up on
> the pages from the print shop, but not our not local (low-res) printers.
> Is this another silent change in fop-1.1 pdf generataion?
>