Subject: embedding all fonts into .pdf - msg#00124

List: editors.lyx.general

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

ICIP 2004 paper upload system requires that _all_ fonts are embedded into
the pdf file (also the 13 standard ones). The tools (pdflatex/ghostscript)
refused initially to do this, and I thought someone would like to hear my
solution or suggest better one. I'm running Debian Stable 3.0.

First, I updated teTeX into version 2 and AFPL Ghostscript into version 8.
Then I replaced file
/etc/texmf/updmap.d/00updmap.cfg
with the new version given in
http://great-white.csee.usf.edu/latex.html
and running update-updmap (the last command is Debian-specific).

This produced embedded fonts from the lyx/tex document, but I had .eps
figures (created with Xfig and gnuplot) that I converted into .pdf with
epstopdf which uses Ghostscript to do the job and the figures still used
non-embedded fonts. My solution was to modify file
/usr/share/gs-afpl/8.14/lib/gs_pdfwr.ps
and change lines

/.standardfonts [
/Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique
/Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique
/Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic
/Symbol /ZapfDingbats
] readonly def

into

/.standardfonts [
% /Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique
% /Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique
% /Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic
% /Symbol /ZapfDingbats
] readonly def

This change looks quite ugly to me, but everything else (specifically using
-dEmbedAllFonts=true) failed. If someone has better solution, let me know.

pdffonts which comes with xpdf proved to be useful. After the above
changes, it showed that all fonts were embedded:

name type emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
SSAHIC+NimbusRomNo9L-Medi Type 1 yes yes no 33 0
UMJGWR+NimbusRomNo9L-ReguItal Type 1 yes yes no 36 0
EFBTTN+NimbusRomNo9L-Regu Type 1 yes yes no 39 0
OVWQVK+CMR10 Type 1 yes yes no 43 0
SBCRSY+CMSY10 Type 1 yes yes no 46 0
BDJSKG+CMMI10 Type 1 yes yes no 56 0
GLEXWD+CMR7 Type 1 yes yes no 59 0
CBLBIL+Times-Roman Type 1C yes yes no 63 0
NXBGXQ+Helvetica Type 1C yes yes no 122 0
NXRCNG+Helvetica Type 1C yes yes no 129 0
FKKSGH+Helvetica Type 1C yes yes no 136 0
FKKSGH+Helvetica Type 1C yes yes no 143 0
FABNJM+Helvetica Type 1C yes yes no 150 0
JODAIJ+Helvetica Type 1C yes yes no 157 0

Thread at a glance:

Previous Message by Date:

problem with oe french ligature

Hello, I tried to use the command\oe for french ligature in the attached LyX file, but it is not compiled. Anybody could say what is wrong in this simple file? THanks a lot for your help and also for the great mailing list so usefull!! Harold --------------------------------------------------------- Harold Mouras Doctorant/ATER Université Paris 5 Inserm U483 Boite 23 9, quai Saint Bernard 75005 Paris Téléphone : +33 1 44 27 26 24 Télécopie : +33 1 44 27 34 38 hmouras@xxxxxxxxxxxxxx harold.mouras@xxxxxxxxxxxxxx ---------------------------------------------------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004 example.lyx Description: Binary data

Next Message by Date:

Re: problem with oe french ligature

Harold Mouras a écrit : Hello, I tried to use the command\oe for french ligature in the attached LyX file, but it is not compiled. Anybody could say what is wrong in this simple file? THanks a lot for your help and also for the great mailing list so usefull!! Harold --------------------------------------------------------- Harold Mouras Doctorant/ATER Université Paris 5 Inserm U483 Boite 23 9, quai Saint Bernard 75005 Paris Téléphone : +33 1 44 27 26 24 Télécopie : +33 1 44 27 34 38 hmouras@xxxxxxxxxxxxxx harold.mouras@xxxxxxxxxxxxxx ---------------------------------------------------------- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004 You should write {\oe} -- Dr. Nicolas Ferre' Laboratoire de Chimie Theorique et de Modelisation Moleculaire UMR 6517 - CNRS Universite' de Provence Case 521 - Faculte' de Saint-Jerome Av. Esc. Normandie Niemen 13397 MARSEILLE Cedex 20 (FRANCE) Tel : (+33)4.91.28.27.33 Fax : (+33)4.91.28.87.58 Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

Previous Message by Thread:

Next Message by Thread:

batch page composition feature request

I think I alluded to this a long while ago, but never followed up. Anyway, here's a feature request --- perhaps the ERT inset could instead be a little pop-up menu populated w/ the number of lines one could gain / lose and the initial value being a comment w/ the number of lines? Say something like: initial menu: [0 (+/-0)] (for a paragraph which can't gain / lose) [0 ( +1/-0] (for a paragraph which can gain one line, but not lose any) [0 (+2/-1] (for a paragraph which can gain two or lose one) and when popped up, the last one would look like: [+2] [+1] [0 (+2/-1)] [-1] Anyway, here's a post I just made to a thread on comp.text.tex about this sort of thing. David Kastrup wrote: >> I am working on typesetting books with quite long paragraphs, a fixed >> line spacing and page layout, where widows on particular and also >> clubs are frowned upon. Given the length of the paragraphs, if TeX >> were to do combined pagebreak/linebreak optimization, most clubs and >> widows could be avoided easily (by effectively using \looseness for >> removing them). As it is, I can only avoid them on pages with >> footnotes, and only by giving sufficiently stretchably interfootnote >> spacing. and Giuseppe asked: >Multipass processes? Well, that's the traditional way to fix it. Find a page w/ a widow or orphan line, look back through the pages, find a paragraph which _might_ be amenable to gaining or losing a line, add \looseness+/-1% before it and re-tex and see. As I've noted in the past, I'd dearly love a mechanism whereby TeX could evaluate a paragraph and note how many lines it could gain or lose and stick that into the output (say as a .pdf annotation). Better still would be if LyX (say) could grab that and add it as an ERT (Evil Red Text --- raw (La)TeX code) comment above each paragraph. It was funny, a while back I posted all that I'd learned of page makeup to the TYPO-L list asking, ``Is there nothing more? Is this all there is to know / do?'' and didn't get a single reply or comment. Later correspondence revealed a number of people had printed out my post, and used it as a guideline in their composition, or when outsourcing.... William (who is also going to post this to the LyX list, in hope some developer there will find it interesting) -- William Adams, publishing specialist voice - 717-731-6707 | Fax - 717-731-6708 www.atlis.com