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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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?
