xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Sargent <rsarg...@xmission.com>
Subject Re: Inter-cell lines no longer "spurious" pdf viewer problem? RESOLVED
Date Fri, 09 Nov 2012 00:19:58 GMT
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 
>>> <mailto:rsargent@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 <mailto:rsargent@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
>>>     <mailto:fop-users-unsubscribe@xmlgraphics.apache.org>
>>>     For additional commands, e-mail:
>>>     fop-users-help@xmlgraphics.apache.org
>>>     <mailto:fop-users-help@xmlgraphics.apache.org>
>>>
>>>
>>
>


Mime
View raw message