Hi, The 'old version' of pdftex had problems with including pdf files that uses fonts not present on the system (well, my system): Font \csname\endcsname=uplr8y not loadable: Metric (TFM) file not found. the new (djgpp) version still has: : invalid font dict type <null> the last couple of days i switched to map files with FontNames again, but i regret that move already. I'm puzzled because i thought that Hartmuts code took care of that. I need to make a decision: either ship with or without FontName entries in map files; (i never had problems without them, but since it was mentioned that inclusion was more efficient with them...) Is it possible to provide \pdfoptionignorefontnames=1 that 'ignores' the font name entries in map files? Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE/POD/CTS Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
The 'old version' of pdftex had problems with including pdf files that uses fonts not present on the system (well, my system):
Font \csname\endcsname=uplr8y not loadable: Metric (TFM) file not found.
What's the point in including a font in a mapfile, if you don't have it? I mean, if I put \garbage into a TeX file, I also get an error message. Thomas
At 23:59 13/05/2004, Thomas Esser wrote:
The 'old version' of pdftex had problems with including pdf files that uses fonts not present on the system (well, my system):
Font \csname\endcsname=uplr8y not loadable: Metric (TFM) file not found.
What's the point in including a font in a mapfile, if you don't have it? I mean, if I put \garbage into a TeX file, I also get an error message.
i put it there because some users asked for it; also, it's not uncommon in tex distibutions to have tfm/vf files without accompanying (non free) pfb or ttf files so, pdftex should ignore entries where a tfm/vf/pfb/ttf/enc file is missing when handling an inclusion (even worse, when one replaces a virtual font with a non virtual one and the doc to be included still has a virtual one, i would not be surprised of problems showing up as well) these things happen and i test such things because of user reports -) Hans
Hi, that's the problem we have been discussing about which fm entry to return for a given base name + slant + extent. I had some discussion with Hartmut, and it should be feasible to implement what I suggested in my previous mail:
For example, we can choose which tfm should be used regard to the following checks (in descending priority):
* the tfm has been used (some char from this font has been typeset) * the tfm has been loaded (but not used yet) * the tfm can be loaded (but not loaded yet) * the tfm is present in map files, but cannot be loaded. In this case a dummy tfm can be loaded instead, and warning should be written
if this is implemented, in your example pdftex would check for all fm entry with the base name 'Palatino-Roman' and select the 'right' one instead of the first one (uplr8y) as it is doing at the moment. Thanh On Thu, May 13, 2004 at 11:26:13PM +0200, Hans Hagen wrote:
Hi,
The 'old version' of pdftex had problems with including pdf files that uses fonts not present on the system (well, my system):
Font \csname\endcsname=uplr8y not loadable: Metric (TFM) file not found.
the new (djgpp) version still has:
: invalid font dict type <null>
the last couple of days i switched to map files with FontNames again, but i regret that move already.
I'm puzzled because i thought that Hartmuts code took care of that.
I need to make a decision: either ship with or without FontName entries in map files; (i never had problems without them, but since it was mentioned that inclusion was more efficient with them...)
Is it possible to provide
\pdfoptionignorefontnames=1
that 'ignores' the font name entries in map files?
Hans
------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE/POD/CTS Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
_______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex
At 05:21 14/05/2004, you wrote:
Hi,
that's the problem we have been discussing about which fm entry to return for a given base name + slant + extent.
I had some discussion with Hartmut, and it should be feasible to implement what I suggested in my previous mail:
For example, we can choose which tfm should be used regard to the following checks (in descending priority):
* the tfm has been used (some char from this font has been typeset) * the tfm has been loaded (but not used yet) * the tfm can be loaded (but not loaded yet) * the tfm is present in map files, but cannot be loaded. In this case a dummy tfm can be loaded instead, and warning should be written
if this is implemented, in your example pdftex would check for all fm entry with the base name 'Palatino-Roman' and select the 'right' one instead of the first one (uplr8y) as it is doing at the moment.
What happens if that file is not really the same? (virtual vs original, special subset with name unchanged, updated metrics); is it possible to store a checksum (i assume private keys are possible in the font dict) and ignore matches with different checksums? Hans
On Fri, May 14, 2004 at 08:50:21AM +0200, Hans Hagen wrote:
At 05:21 14/05/2004, you wrote:
Hi,
that's the problem we have been discussing about which fm entry to return for a given base name + slant + extent.
I had some discussion with Hartmut, and it should be feasible to implement what I suggested in my previous mail:
For example, we can choose which tfm should be used regard to the following checks (in descending priority):
* the tfm has been used (some char from this font has been typeset) * the tfm has been loaded (but not used yet) * the tfm can be loaded (but not loaded yet) * the tfm is present in map files, but cannot be loaded. In this case a dummy tfm can be loaded instead, and warning should be written
if this is implemented, in your example pdftex would check for all fm entry with the base name 'Palatino-Roman' and select the 'right' one instead of the first one (uplr8y) as it is doing at the moment.
What happens if that file is not really the same? (virtual vs original, special subset with name unchanged, updated metrics);
is it possible to store a checksum (i assume private keys are possible in the font dict) and ignore matches with different checksums?
can you clarify it a bit more? I don't understand what you want to do here. When you talk about eg Palatino-Roman, we suppose you have somewhere on your disk a fontfile with that FontName entry inside the font. If you have several entries with the same FontName but different fontfile, I consider it a fatal error that should be fixed in the map files. Thanh
At 09:27 14/05/2004, The Thanh Han wrote:
can you clarify it a bit more? I don't understand what you want to do here. When you talk about eg Palatino-Roman, we suppose you have somewhere on your disk a fontfile with that FontName entry inside the font. If you have several entries with the same FontName but different fontfile, I consider it a fatal error that should be fixed in the map files.
Imagine that you processed a file in 2001 using a certain font setup (could be a pdftex file, but also one produced by GS or whatever) and wants to include a page from that file in a document in 2004. How can you be sure that in spite of the name, the font is exactly teh same? It could be an update, or a subset, or the new one could have more glyphs (euros added for instance). I just found out that for obscure reasons the urw paths became urw35vf and users who copy trees over old trees may have ended up with duplicates (old ones are found then due to alphabetical searching) etc etc. it's a mess out there and it's not going to improve soon, so pdftex should be as clever as possible. It's better have too many fonts in a file (duplicates) then to get the wrong ones. So the question is, what to check for and when to ignore. Keep in mind that people get files from everywhere (i'm dealing with files from all kind of applications and esp those urw files are all over the place and we cannot know how/what people changed; btw, this is one reason why i'm glad that fonts are often copyrighted). If you provide this \pdfoptionsignorefontname or maybe \pdfoptionsfontmethod or whatever, at least we have some control, else i have to ship a double set of map files (i just wrote a stripper) for the sake of robust inclusion. I have to make a decision because i don't want to keep messing aroudn with the distribution (tex live deadlines and so). Hans
Hans, let's make things simple. For `proper inclusion' you don't need a double set of map files. When a pdf file is being included, all the metrics & encodings are copied, just font files are passed to pdftex if the font names are found in map files. So given a font in a pdf figure, when you include this figure there are 2 options: 1) font name is not found in map files: then it is copied 2) font name is found in map files: it should be handled by pdftex if possible, otherwise it should be copied. The point is what `possible' means here. There are two requirements: a) the font file is avail. to pdftex; this check has been done by Hartmut b) the metric is avail. to pdf: this check is being discussed now. If you need more fine control, we can extend the mechanism so all fonts in an included pdf are copied if needed (for example by giving a keyword after \pdfximage), regardless whether their names are found in map files or not. Thanh
Imagine that you processed a file in 2001 using a certain font setup (could be a pdftex file, but also one produced by GS or whatever) and wants to include a page from that file in a document in 2004. How can you be sure that in spite of the name, the font is exactly teh same? It could be an update, or a subset, or the new one could have more glyphs (euros added for instance). I just found out that for obscure reasons the urw paths became urw35vf and users who copy trees over old trees may have ended up with duplicates (old ones are found then due to alphabetical searching) etc etc. it's a mess out there and it's not going to improve soon, so pdftex should be as clever as possible. It's better have too many fonts in a file (duplicates) then to get the wrong ones. So the question is, what to check for and when to ignore. Keep in mind that people get files from everywhere (i'm dealing with files from all kind of applications and esp those urw files are all over the place and we cannot know how/what people changed; btw, this is one reason why i'm glad that fonts are often copyrighted).
If you provide this \pdfoptionsignorefontname or maybe \pdfoptionsfontmethod or whatever, at least we have some control, else i have to ship a double set of map files (i just wrote a stripper) for the sake of robust inclusion. I have to make a decision because i don't want to keep messing aroudn with the distribution (tex live deadlines and so).
Hans
participants (3)
-
Hans Hagen -
The Thanh Han -
Thomas Esser