You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@tpg.com.au> on 2004/05/28 01:15:26 UTC
Re: Printing to paper edge for a "bleed tab"
I suppose that everyone has noticed this exchange on fop-user.
Peter
Mike Kellstrand wrote:
> Mark,
>
> I ran the PDF through Ghostscript and it looks like it is doing the trick.
> I did notice that the same PDF printed in Ghostscript vs. Adobe print
> out with slightly different size fonts. Arg! :)
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Printing to paper edge for a "bleed tab"
Posted by ar...@cappelino.de.
Clay Leeds <cl...@medata.com> wrote 28.05.2004 17:57:59:
> The nice thing about this, is that one could set up parameters (stored
> in config files), to help determine how the output would be rendered.
> The 'holder' could consult the config file to determine how to proceed.
>
> Among the items in the config file:
> - minimum margins (t r b l)
> - acceptable fonts
> - font re-mapping?
> - definition of the 'any' font when font not found
> There could also be separate sections based on the renderer, so
> Postscript output could add job-control/paper-tray selection
> information as well.
Yes, sure. The only thing I would still want is that you dont't
*have to* specify all this, and also that it's possible to have
a per-document paramterization for that. Config file only is not
feasible in many environments. I often tend to think of an FO
stream as a "job to process", not a document. A job should be
able to contain everything necessary.
> OT:
> I thought Italy was the place with the largest 'organization' of ideas
> :-)
Used to be. They outsourced all of that to a company with a CEO named
Berlusconi if I remember correctly. 8-)
--
Arnd Beißner
Cappelino Informationstechnologie GmbH
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99
Mobile: +49-173-3016917
Re: Printing to paper edge for a "bleed tab"
Posted by Clay Leeds <cl...@medata.com>.
On May 28, 2004, at 8:26 AM, arnd.beissner@cappelino.de wrote:
> "Peter B. West" <pb...@tpg.com.au> schrieb am 28.05.2004 17:16:08:
>> Thanks Arnd. My argument is that the renderer must tell the layout
>> engine about font metrics. I have always regarded PDF and PS (with
>> obligatory fonts) as stable targets in this respect.
>
> They are. PostScript files and PDF should not be created with specifics
> of an output device in mind. The only thing that may happen is that
> you directly add job-control features to PostScript file - for example
> paper try switching. Please be aware that the difficulties I mention
> are
> in the chain Acrobat->printer and PSFile->printer, NOT in the chain
> formatter->renderer.
>
>> It's reassuring to find that there are so many ways in which
>> variations
>> will creep in to the output of even such a heavily standardised
>> format as PDF. To get the output point-perfect then, the renderer
>> needs to know the peculiarities of the output device.
>
> My take on this is - as I hopefully have been able to communicate -
> that the renderer should tell the formatter what it *can* do. This
> includes but is not restricted to fonts or font metrics. The *holder*
> (I deliberately do not say owner here) of this kind of information
> should be the formatter (or a separate centralized entity that
> the formatter can access). The formatter can also hold information
> of its own - like for example a repository of TTF or Type 1 fonts
> that all renderers wo are able to handle this type of font can
> subsequently make use of.
This type of system sounds more like a three tiered system:
- data
- logic (business logic)
- output
or in this case:
- formatter
- holder of information
- renderer
The nice thing about this, is that one could set up parameters (stored
in config files), to help determine how the output would be rendered.
The 'holder' could consult the config file to determine how to proceed.
Among the items in the config file:
- minimum margins (t r b l)
- acceptable fonts
- font re-mapping?
- definition of the 'any' font when font not found
There could also be separate sections based on the renderer, so
Postscript output could add job-control/paper-tray selection
information as well.
> Like in a federalistic political system, this structure makes sure
> that everyone can give his input into the decision process.
> You just have to make sure that there is just *one* entity
> responsible for the final decision - otherwise, you're in Germany.. 8-)
OT:
I thought Italy was the place with the largest 'organization' of ideas
:-)
Of course...
Democracy is the worst form of government... except for all the others.
- Winston Churchill
Web Maestro Clay - <we...@mac.com>
---
My religion is simple. My religion is kindness.
- His Holiness the 14th Dalai Lama of Tibet
Re: Printing to paper edge for a "bleed tab"
Posted by ar...@cappelino.de.
"Peter B. West" <pb...@tpg.com.au> schrieb am 28.05.2004 17:16:08:
> Thanks Arnd. My argument is that the renderer must tell the layout
> engine about font metrics. I have always regarded PDF and PS (with
> obligatory fonts) as stable targets in this respect.
They are. PostScript files and PDF should not be created with specifics
of an output device in mind. The only thing that may happen is that
you directly add job-control features to PostScript file - for example
paper try switching. Please be aware that the difficulties I mention are
in the chain Acrobat->printer and PSFile->printer, NOT in the chain
formatter->renderer.
> It's reassuring to find that there are so many ways in which variations
> will creep in to the output of even such a heavily standardised
> format as PDF. To get the output point-perfect then, the renderer
> needs to know the peculiarities of the output device.
My take on this is - as I hopefully have been able to communicate -
that the renderer should tell the formatter what it *can* do. This
includes but is not restricted to fonts or font metrics. The *holder*
(I deliberately do not say owner here) of this kind of information
should be the formatter (or a separate centralized entity that
the formatter can access). The formatter can also hold information
of its own - like for example a repository of TTF or Type 1 fonts
that all renderers wo are able to handle this type of font can
subsequently make use of.
Like in a federalistic political system, this structure makes sure
that everyone can give his input into the decision process.
You just have to make sure that there is just *one* entity
responsible for the final decision - otherwise, you're in Germany.. 8-)
More on this later - I still owe Victor an answer.
Arnd
--
Arnd Beißner
Cappelino Informationstechnologie GmbH
Re: Printing to paper edge for a "bleed tab"
Posted by "Peter B. West" <pb...@tpg.com.au>.
arnd.beissner@cappelino.de wrote:
> "Peter B. West" <pb...@tpg.com.au> wrote on 28.05.2004 01:15:26:
>
>
>>I suppose that everyone has noticed this exchange on fop-user.
>>
>>Peter
>>
>>Mike Kellstrand wrote:
>>
>>>Mark,
>>>
>>>I ran the PDF through Ghostscript and it looks like it is doing the
>
> trick.
>
>>>I did notice that the same PDF printed in Ghostscript vs. Adobe print
>>>out with slightly different size fonts. Arg! :)
>
>
> Is there a specific reason for this pointer?
>
> If there is any doubt: font sizes are the same whereever you print out a
> PDF
> - as long as the PDF viewer application and the printer(driver) work
> correctly
> and the user hasn't made any mistake.
>
> Possible causes for this kind of problem:
>
> 1. The printer (or emulator) does not use exactly the same font, but a
> substitute
> with differing metrics. GhostScript default fonts are not perfectly
> compatible
> with the metrics of the Adobe base fonts - that goes at least for
> GhostScript
> version from about a year ago.
>
> 2. This is a variation of 1. Improper setting of font match settings in
> the
> printer driver options. Using device fonts in PCL printing is especially
> dangerous as many drivers then don't handle Z-order or font color
> correctly in
> addition to having device fonts with metrics that match only to 95% or so.
>
> 3. The user has made a mistake (page/paper scaling options if the Acrobat
> print
> dialog, like fit to page, etc.).
>
> 4. The PostScript printer (or emulation) or the printer driver is buggy.
> The
> Kyocera PS emulation is a little shaky in my experience - though not
> regarding
> font sizes or metrics regarding the base fonts.
>
> We have done lots and lots of PDF and PostScript output for a bunch
> customers
> with an output of several 100.000 pages per month (by the way: more than
> 50%
> of these still done with FOP) and using dozens of different printers, and
> a number of fonts (base fonts as well as others). Any font size or metric
> problems during the last years regarding PDFs or PSes could be resolved to
> one
> of the 4 reasons - most popular is 3.
>
> Hope this resolves any doubt you might have.
Thanks Arnd. My argument is that the renderer must tell the layout
engine about font metrics. I have always regarded PDF and PS (with
obligatory fonts) as stable targets in this respect. It's reassuring to
find that there are so many ways in which variations will creep in to
the output of even such a heavily standardised format as PDF. To get
the output point-perfect then, the renderer needs to know the
peculiarities of the output device.
I'm not suggesting this, but I would expect these considerations to
temper a little the enthusiasm for centralised font handling.
I thought my meaning more evident than it evidently was.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Printing to paper edge for a "bleed tab"
Posted by ar...@cappelino.de.
"Peter B. West" <pb...@tpg.com.au> wrote on 28.05.2004 01:15:26:
> I suppose that everyone has noticed this exchange on fop-user.
>
> Peter
>
> Mike Kellstrand wrote:
> > Mark,
> >
> > I ran the PDF through Ghostscript and it looks like it is doing the
trick.
> > I did notice that the same PDF printed in Ghostscript vs. Adobe print
> > out with slightly different size fonts. Arg! :)
Is there a specific reason for this pointer?
If there is any doubt: font sizes are the same whereever you print out a
PDF
- as long as the PDF viewer application and the printer(driver) work
correctly
and the user hasn't made any mistake.
Possible causes for this kind of problem:
1. The printer (or emulator) does not use exactly the same font, but a
substitute
with differing metrics. GhostScript default fonts are not perfectly
compatible
with the metrics of the Adobe base fonts - that goes at least for
GhostScript
version from about a year ago.
2. This is a variation of 1. Improper setting of font match settings in
the
printer driver options. Using device fonts in PCL printing is especially
dangerous as many drivers then don't handle Z-order or font color
correctly in
addition to having device fonts with metrics that match only to 95% or so.
3. The user has made a mistake (page/paper scaling options if the Acrobat
print
dialog, like fit to page, etc.).
4. The PostScript printer (or emulation) or the printer driver is buggy.
The
Kyocera PS emulation is a little shaky in my experience - though not
regarding
font sizes or metrics regarding the base fonts.
We have done lots and lots of PDF and PostScript output for a bunch
customers
with an output of several 100.000 pages per month (by the way: more than
50%
of these still done with FOP) and using dozens of different printers, and
a number of fonts (base fonts as well as others). Any font size or metric
problems during the last years regarding PDFs or PSes could be resolved to
one
of the 4 reasons - most popular is 3.
Hope this resolves any doubt you might have.
Bye,
Arnd
--
Arnd Beißner
Cappelino Informationstechnologie GmbH