tetex: pdftex / updmap pdftexDownloadBase14

339 Aufrufe
Direkt zur ersten ungelesenen Nachricht

i a welch

ungelesen,
22.08.2005, 11:01:5422.08.05
an

dear (pdf)tex wizards: I am trying to upload a book to lulu for
print-on-demand. Alas, I was surprised that they require even the 14
base pdf fonts embedded.

not a problem, me thinks---google for a while, and I learn that the
magic for tetex-3.0-r2 sits in updmap (it would be nice if this was an
optional argument to pdftex itself). So, I tried as root
updmap --setoption pdftexDownloadBase14 true
A whole lot of output scrolls by, and I thought this would be it. no
dice. the resulting document on re-pdflatex still tells my acroread
program that it uses these fonts and that they are not embedded. then
I try the same game with the downloadbase set to false--it seems to
make no difference. could someone please enlighten me how to embed
them?

of course, I could be totally wrong here. the helvetica and other
fonts come from enclosed figures (created by R), not from the latex
document itself. but it would seem rather inefficient to include the
full fonts for each and every R figure in my document rather than to
ask pdftex to just include the font once at the outset.

regards,

/iaw

Walter Schmidt

ungelesen,
22.08.2005, 11:52:5022.08.05
an
i a welch schrieb:

> the helvetica and other
> fonts come from enclosed figures (created by R), not from the latex

> document itself. [...]


> the resulting document on re-pdflatex still tells my acroread
> program that it uses these fonts and that they are not embedded.

Most likely, you don't have the "real" Helvetica, since it is a
commercial typeface. TeX is using a free substitute (Nimbus Sans)
instead, and pdfTeX _can_ indeed embed the latter, but pdfTeX is
_not_ able to satisfy the references to "Helvetica" in the EPS
figures, because it just does not have this font (and because it is
not a full-blown Distiller).

There are various solutions:

> but it would seem rather inefficient to include the
> full fonts for each and every R figure in my document rather than to
> ask pdftex to just include the font once at the outset.

I agree that it's inefficient, but that's in fact solution #1:

I suppose you are converting the EPS figures to PDF, in order to
let pdfTeX import them. Use ps2pdf (Ghostscript) for the conversion
and make Ghostscript embed all fonts. As a result, Ghostscript will
use Nimbus Sans where Helvetica is requested.

Solution #2 would be to ask "R" to "embed the fonts as graphics",
provided that the progam provides this facility at all. (I don't
know.) Doing so can avoid many problems -- at the cost of printing
quality, however

Let's skip solutions #3, #4 and #5 for the time being; they require
far more effort...

HTH
Walter

Daniel Oehry

ungelesen,
22.08.2005, 12:40:0022.08.05
an
On Mon, 22 Aug 2005 08:01:54 -0700, i a welch wrote:

>
> dear (pdf)tex wizards: I am trying to upload a book to lulu for
> print-on-demand. Alas, I was surprised that they require even the 14 base
> pdf fonts embedded.
>
> not a problem, me thinks---google for a while, and I learn that the magic
> for tetex-3.0-r2 sits in updmap (it would be nice if this was an optional
> argument to pdftex itself). So, I tried as root
> updmap --setoption pdftexDownloadBase14 true

Could it be you are running gentoo? If so, edit the
file /etc/texmf/updmap.d/00updmap.cfg and change the
line

pdftexDownloadBase14 false

to

pdftexDownloadBase14 false

After that run the script texmf-update as root and you will be fine!

Daniel

i a welch

ungelesen,
22.08.2005, 15:56:3522.08.05
an

Hi Daniel: Indeed, I am running gentoo. I presume that you wanted me
to change this to "pdftexDownloadBase14 true", which I duly did, then
ran texmf-update, but pdffonts still tells me that the 13 base fonts
are not embedded. Sigh...

regards,

/iaw

i a welch

ungelesen,
22.08.2005, 16:01:3222.08.05
an

Hi Walter: Actually, I am creating pdf files directly in R, which is
a very nice feature of R.

But I cannot figure out what is necessary to get ghostscript to embed
the fonts. I am now running ghostscript ADFL 8.51, which I downloaded
to make sure that I am working with something reasonably recent. I
figured the easiest would be to tinker with the pdfopt script---the
linearization is not a bad thing to get for free either. I tried the
obvious switches, but they don't fix the problem either.

exec $GS_EXECUTABLE -q -dSAFER -dEmbedAllFonts=true -dSubsetFonts=true
-dCompatibilityLevel=1.3 -sDEVICE=pdfwrite -dPDFSETTINGS=/printer
-dNODISPLAY $OPTIONS -- pdfopt.ps "$1" "$2"

Is there a magic incantation that I am still missing?

regards,

/ivo welch

Daniel Oehry

ungelesen,
22.08.2005, 17:30:5322.08.05
an

Sorry for the typo:-)

Could you provide a minimal example of your tex-file? Maybe it has
something to do with your R-graphics. Could you provide a sample of
these too? Have you tried if e.g. Times in a LaTeX-file is embeded? What
is the output of the following?

\documentclass{article}
\usepackage{mathptmx}
\begin{document}
This should be Times.
\end{document}

Daniel

i a welch

ungelesen,
22.08.2005, 17:52:5422.08.05
an

Hi Daniel: Actually, I just looked at my other vanilla machine, and
"pdftexDownloadBase14 true" was properly set already. More
importantly, your example properly embeds a postscript font in the
latex document---but unfortunately not the standard adobe font.
Instead, it embeds the nimbus font equivalent. As long as I stay
fully within latex without graphics inclusion, this is great.

The R graphics, however, relies on the real adobe font, which the
nimbus font inclusion cannot cure. Only the inclusion of the actual
Adobe font could cure this, because the fonts are named.

$ pdffonts test.pdf (test.tex has an includegraphics to an R plot):
<pre>
name type emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
OEOHPW+NimbusRomNo9L-Regu Type 1 yes yes no 7 0
ZapfDingbats Type 1 no no no 10 0
Helvetica Type 1 no no no 11 0
Helvetica-Bold Type 1 no no no 12 0
Helvetica-Oblique Type 1 no no no 13 0
Helvetica-BoldOblique Type 1 no no no 14 0
Symbol Type 1 no no no 15 0
<pre>

If I understand the licensing issues now, pdftex is unable to include
the adobe fonts legally. The latex graphicx package is written only
for plain inclusion, not for font-replacement during inclusion. So, I
really need a post-processor that can strip out adobe fonts from a pdf
file and replace them with open equivalents (preferably even if the
font appears only midway in the document in an included (encapsulated)
pdf file). I guess ghostscript can in principle do this, although I do
not yet know how.

I hate this font mess!

regards,

/iaw

Walter Schmidt

ungelesen,
22.08.2005, 20:31:1922.08.05
an
i a welch schrieb:

> Hi Walter: Actually, I am creating pdf files directly in R, which is
> a very nice feature of R.

A program that creates PDF _without_ embedding all fonts isn't "nice".

> But I cannot figure out what is necessary to get ghostscript to embed
> the fonts. I am now running ghostscript ADFL 8.51, which I downloaded
> to make sure that I am working with something reasonably recent. I
> figured the easiest would be to tinker with the pdfopt script---the

I'm not familiar with pdfopt -- I'm sorry.

> linearization is not a bad thing to get for free either. I tried the
> obvious switches, but they don't fix the problem either.
>
> exec $GS_EXECUTABLE -q -dSAFER -dEmbedAllFonts=true -dSubsetFonts=true
> -dCompatibilityLevel=1.3 -sDEVICE=pdfwrite -dPDFSETTINGS=/printer
> -dNODISPLAY $OPTIONS -- pdfopt.ps "$1" "$2"

A wild guess: Try -dPDFSETTINGS=/prepress instead of /printer.

If this does not help:
Let R create Postscript and feed the ouput to ps2pdf, using also the
options "-dPDFSETTINGS=/prepress -dCompatibilityLevel=1.3" This works
perfectly here.

HTH
Walter

Ralf Stubner

ungelesen,
23.08.2005, 03:34:5023.08.05
an
Walter Schmidt <w.a.s...@fantasymail.de> writes:

> Let R create Postscript and feed the ouput to ps2pdf, using also the
> options "-dPDFSETTINGS=/prepress -dCompatibilityLevel=1.3" This works
> perfectly here.

Despite the name ps2pdf can also be used for pdf->pdf processing:

~/tex/tmp$ ps2pdf13 -dPDFSETTINGS=/prepress foo.pdf bar.pdf
~/tex/tmp$ pdffonts foo.pdf


name type emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------

Times-Roman Type 1 no no no 10 0
~/tex/tmp$ pdffonts bar.pdf


name type emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------

ITAAAA+Times-Roman Type 1C yes yes no 11 0

Note that the Times-Roman in bar.pdf is actually 'Nimbus Roman No9 L' in
disguise. Also, ps2pdf1<x> is just a short hand for 'ps2pdf
-dCompatibilityLevel=1.<x>'.

cheerio
ralf

Daniel Oehry

ungelesen,
23.08.2005, 05:41:0423.08.05
an
On Mon, 22 Aug 2005 14:52:54 -0700, i a welch wrote:

> The R graphics, however, relies on the real adobe font, which the nimbus
> font inclusion cannot cure. Only the inclusion of the actual Adobe font
> could cure this, because the fonts are named.

I do not know R, but isn't it possible to change the default font to
Nimbus-Sans?

[...]

>
> If I understand the licensing issues now, pdftex is unable to include the
> adobe fonts legally.

This is not true. If you own the original Adobe fonts legally it is
possible to use them with pdftex instead of the URW replacements. You just
have to change the respective font-map files (for gentoo see
/etc/texmf/updmap.d/00updmap.cfg).

> The latex graphicx package is written only for plain
> inclusion, not for font-replacement during inclusion. So, I really need a
> post-processor that can strip out adobe fonts from a pdf file and replace
> them with open equivalents (preferably even if the font appears only
> midway in the document in an included (encapsulated) pdf file). I guess
> ghostscript can in principle do this, although I do not yet know how.

See Walters and Ralfs postings for an answer to this.

Daniel

i a welch

ungelesen,
23.08.2005, 09:50:0123.08.05
an

Hi Ralf/Daniel/Walter:

Thank you very much for your help. This ghostscript ps2pdf13 (or
ps2pdf14), applied on the included figures, really did the job for me.
The trick was knowing that it would also work on pdf files. Brillant.

I have one remaining oddity---ps2pdf14 seems to change the orientation
of some pdf files---and seemingly randomly. two files produced with
the same program and same dimensions come out differently, one portrait
and one landscape. naturally, this wreaks havoc in the
\includegraphics statement. but this is an issue I can figure out...

Thank you again.

regards,

/iaw

i a welch

ungelesen,
23.08.2005, 11:20:2723.08.05
an

ha! the answer to random figure rotation is to use a setting of
printer, not prepress---and the AutoRotatePages parameter will be set
to /None.

regards, /iaw

Allen antworten
Dem Autor antworten
Weiterleiten
0 neue Nachrichten