[pdftex] multiple embedded pdf figures
ivowel at gmail.com
Fri Nov 25 21:58:16 CET 2005
hi hans: thank you for your help. my OS is gentoo linux. I was easily
able to upgrade to ghostscript-afpl 8.53. thanks, gentoo.
alas, the old book.pdf file, created by pdfetex 1.21, with enclosed R
graphics files, still produces
Error: /typecheck in --lt--
--dict:6/6(L)-- --nostringval-- --nostringval-- Color
--nostringval-- Rect --nostringval-- Border --nostringval--
--dict:8/12(L)-- (chapter.7) Names --nostringval-- 0
--dict:2/2(L)-- (table.B.1) --dict:8/12(L)--
of course, because I have embedded pdf files, this error could be caused by
some of the embedded pdf files, and I would never know. [Suggestion for
pdftex---is there any way that embedded filenames can be passed to
ghostscript, so that ghostscript tells me which file [or the main file] it
is carping about? this may be technically totally unfeasible, given current
setup and level of difficulty to do this.]
so, my natural next try should be to try to upgrade pdftex. this one is
scarier. tetex upgrades are easy, because they are handled through gentoo.
but tetex 3.0 seems to be the latest version, and it is based on 1.21.
- is this an easy binary replacement, or does it require a lot more
detail? I guess I will try it,
so I will find out. :-).
- will it likely do anything for me? that is, if it creates a pdf file
that can be run through
ghostscript, will this eliminate font duplicate name issues?
there are very few convenient book-on-demand printers. the one I am using
is lulu, which seems to be among the bigger and more convenient ones. It
charges about 10% above cost, which is also pretty good---an 800 page book,
perfect-bound, for around $20. customers can purchase the book, it gets
printed and shipped by them. nice. I wish there was a more pdflatex
competent lulu. Does anyone have good alternative book-on-demand printer
On 11/25/05, Hans Hagen <pragma at wxs.nl> wrote:
> ivo welch wrote:
> ><i>"I see that your pdf was created with pdfeTeX-1.21a. You can view
> you use a bit ancient version, maybe the latest performs different
> >the font substitution error you are witnessing. When the printer rips
> >your pdf, it looks at the embedded font subset to obtain the character
> >to print. When you have mulitple subsets with the same name, many
> >times it will choose the wrong one. It seems that merging multiple
> so the printer is bugged
> >the best option that I can think of. You might also want to try a
> >different pdf producer such as Adobe Distiller or InDesign."</i>
> try another printer -)
> >he is of course correct about the pdf file:
> ># pdffonts book.pdf
> ><many lines, incl>
> >TCFXGM+LucidaBright Type 1 yes yes no 25 0
> >TCFXGM+LucidaBright Type 1 yes yes no 5081 0
> >TCFXGM+LucidaBright Type 1 yes yes no 5294 0
> >the latter two come from pdf figure files that have been created by R (a
> >statistical package), which (because R is incapable of embedding fonts
> >themselves) receive their embedded font through one run through ps2pdf14
> >(gs 7.07.1). finally, these ghostscript-distilled graphics are embedded
> forget about 7.07, you need at least > 8 to get proper pdf, and
> preferable > 8.30 and if you do fancy color stuff, go for > 8.50
> >by \includegraphics. naturally, they can come out with the same names.
> >it appears that pdftex does not use own font namespaces in
> >includegraphics. R cannot do it, because it creates only one figure at
> >a time (it has no history of what other font names earlier runs
> >elsewhere have created).
> it should not really be a problem, since all the viewer has to do is to
> follow the object links;
> >an additional run of my big pdftex-created book.pdf file through
> >ps2pdf14 18.104.22.168 results in a /typecheck in --lt-- error, so this is not
> >a solution, either.
> >I hope I am not the first person to have run into this problem. how can
> >I solve this problem?
> best update to pdftex > 1.30 and gs > 8.50 and see what happens then
> pdftex mailing list
> pdftex at tug.org
More information about the pdftex