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?
Date Mon, 05 Nov 2012 22:25:28 GMT
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.


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 
> <mailto:rsargent@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 <mailto:rsargent@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 <mailto:rsargent@xmission.com>>
>>>>             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?

View raw message