Re: [tex-k] Dvips fix for font in EPSF improperly downloaded
All your points are good, but I clain the "fix" is still an improvement, and for that reason I am leaving it in there. Perhaps I am naive, but if someone gives me an environment in which there are multiple, and distinctly different, fonts, with the same /FontName, I claim all bets are off. I have encountered this before and it's not a good situation. At this time I simply don't have a solution for a case like this. On the other hand, I do agree that it is better to rename the TeX fonts if we will partially subset them. I believe we should do this (assuming technically we can make it work; I do not know that we cannot, nor do I know of specific issues, but I would not be surprised if this breaks something). Of course there are legal issues with renaming a font too, most likely. :-) This is something to consider for the next release (not only of dvips but also of pdftex, I believe). But I believe this is a substantial change to a piece of code that I am simply not familiar enough with to mess with. I do know that I have had in the past substantial problems with just changing the UniqueID of the font; different interpreters were very unhappy with some of the changes I made and I had to back them out. But that's just a technical issue. On the legal issue: I agree a warning may be appropriate whenever a font is included in its entirety. Right now dvips turns a deaf ear to these issues, but it is perhaps time for it to support at the very least a warning message. Another alternative is to run all included graphics through a companion interpreter that's been configured to only collect information on what characters and what fonts are used (probably by redefining show and a few other operators). But this is another substantial undertaking. Just so we are very clear: is it your position that this change that was made should be reversed? Or improved before the next release? Both of these positions would be troublesome for me. If it's just a question of, here's some additional issues to consider and let's try to get a solution to them as quickly as possible, I could not agree more. I must say that I've had no indication that the problems you mention are severe (i.e., causing problems for people), but perhaps that is because I don't follow most of the TeX groups. I believe this is a discussion that we should have as part of a larger group, so I am happy to have gotten your note, and I hope our collected wisdom on these groups will steer us all in the appropriate direction. But for now I've got to get a point release out the door. -tom
I agree a warning may be appropriate whenever a font is included in its entirety. May I suggest a modification: whenever a *proprietary* font (that is, one with the restrictive licensing) is included. It would be quite a lot of noise to generate a warning for every fully-included font, as most commonly-used fonts in the TeX world are free. Seems like any "real" warning regarding problematic fonts would quickly be lost in the swamp of resulting messages. The only thing I can think of is some kind of additional map file option (ugggh) to generate the warning. Then when people (like Walter) generate TeX support for proprietary fonts, the pregenerated map files can specify the new option. Further: any changes to map file syntax should be coordinated with pdftex and dvipdf[m][x], as another long-term goal should be to re-unify map files so that the same syntax can be used for all programs. It is a hassle for TeX Live and other distributions to have maintain the same information in three formats with only tiny differences. Also, I'm not sure if this is already included in the discussion, but any such warning should presumably apply when the font is fully downloaded at all, independent of whether that happens due to an .eps inclusion or simply using the font in the document. At this time he was thinking about changing /FontName in the free URW fonts on CTAN I sincerely hope Walter does not do that. Seems like it would have major backward-compatibility implications. karl
On Sun, 23 Jan 2005, Karl Berry wrote:
At this time he was thinking about changing /FontName in the free URW fonts on CTAN
I sincerely hope Walter does not do that. Seems like it would have major backward-compatibility implications.
e. g. there would be problems with pdftex: while trying to replace fonts coming with PDF files to be embedded, pdftex would not match the traditional fontnames any more and would fail replacing fonts (like /Times-Roman), then the whole font replacement business would be practically broken, resulting in larger filesize in these cases. Same if one would also check for matching UniqueId field. So maybe it's better that it remains fuzzy as is (with a few sideeffects). Or maybe invent a font name alias mechanism as Fontmap from gs. Regards, Hartmut
Karl Berry wrote:
May I suggest a modification: whenever a *proprietary* font (that is, one with the restrictive licensing) is included.
It would be quite a lot of noise to generate a warning for every fully-included font, as most commonly-used fonts in the TeX world are free. Seems like any "real" warning regarding problematic fonts would quickly be lost in the swamp of resulting messages.
if that kind of crappy messages are really needed, then please only to the log file and optional
The only thing I can think of is some kind of additional map file option (ugggh) to generate the warning. Then when people (like Walter) generate TeX support for proprietary fonts, the pregenerated map files can specify the new option.
that will become a never ending story then; there are all kind of thinsg going on: - you may mess up the design, metrics, glyph programs all under the same name [no fonts] - you may mess up the design, metrics, glyph programs all under a different name [cmr] - you may use the font, make virtual instances, change metrics, but need to keep the design intact (may not create clones) [like utopia] - you may use the font, but not distribute file that contain all glyphs at the same time [lucida] i'm not even sure what category the palatino falls in: since there is an official one -from linotype- i even wonder if we may call all those variants on tex live palatino at all; it's funny that we're discussing them as being 'programs' i.e. some gpl being applied to them while part of the copyright [at least on the type 1's] not concerns the 'implementation' but the design, which deserves its own kind of licence [artistic ownership and such];
Further: any changes to map file syntax should be coordinated with pdftex and dvipdf[m][x], as another long-term goal should be to re-unify map files so that the same syntax can be used for all programs. It is a hassle for TeX Live and other distributions to have maintain the same information in three formats with only tiny differences.
hm, not change, dvipdfmx and dvips should just use the pdftex one (i need to check it, but some time ago the dvipdfmx people were working along those lines, including runtime mapfile/line definitions)
Also, I'm not sure if this is already included in the discussion, but any such warning should presumably apply when the font is fully downloaded at all, independent of whether that happens due to an .eps inclusion or simply using the font in the document.
At this time he was thinking about changing /FontName in the free URW fonts on CTAN
I sincerely hope Walter does not do that. Seems like it would have major backward-compatibility implications.
normally the copyright lines that are part of a font are copied into the pdf file along with the shape definitions, metric info, etc etc; so .. that part should be correct. [i think that as soon as users start seeing funny font copyright messages at runtime, they will stop using the fonts, and in the end we will end up with cmr only files] Hans btw i have no problem with copyrighted font designs, as long as we may mess around with the metrics, which is normally no problem since all dtp programs mess around with them when typesetting text, so messing around is part of the game; actually, messing around with the shapes is also permitted since that can be done in most vector drawing programs, as long as one does not produce and distribute a new font; so ... i do't really see the problem; ever since pdf was around, the only problems has been: - some font vendors don't permits any font to be part of a posted pdf; solution: i simply refuse to use such fonts - some font vendors don't permits a complete instance to be part of a posted pdf, since usa law than seems to imply that the font is kind of public since someone with a twisted mind can copy the font from the file and use it; solution: always embed subsets, which is kind of default behaviour for pdftex ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
"Karl" == Karl Berry
writes:
I agree a warning may be appropriate whenever a font is included in its entirety.
May I suggest a modification: whenever a *proprietary* font (that is, one with the restrictive licensing) is included.
It's probably too hard to find out which font is proprietary.
It would be quite a lot of noise to generate a warning for every fully-included font, as most commonly-used fonts in the TeX world are free. Seems like any "real" warning regarding problematic fonts would quickly be lost in the swamp of resulting messages.
dvips already lists all fonts on STDOUT, isn't it sufficient to put an asterisk behind each font that had been loaded entirely and then issue a message like "*) Some Fonts had not been subsetted" at the end if at least one asterisk appears? The message is just an example. It should be understood by people who do not know what subsetting is. But English is not my native language, feel free to provide better suggestions. Hans, is this ok for you? Or is it still too crappy?
The only thing I can think of is some kind of additional map file option (ugggh) to generate the warning. Then when people (like Walter) generate TeX support for proprietary fonts, the pregenerated map files can specify the new option.
I don't see that there is any need to change the map files. Usually there is no need to download an entire font. The map files provided by TeX distributions are set up to do subsetting by default. My only concern is that people rely on this and do not notice that they violate against licenses because something happens in the background they are not aware of.
Further: any changes to map file syntax should be coordinated with pdftex and dvipdf[m][x], as another long-term goal should be to re-unify map files so that the same syntax can be used for all programs. It is a hassle for TeX Live and other distributions to have maintain the same information in three formats with only tiny differences.
Of course.
Also, I'm not sure if this is already included in the discussion, but any such warning should presumably apply when the font is fully downloaded at all, independent of whether that happens due to an .eps inclusion or simply using the font in the document.
Sounds quite straightforward: An asterisk for each font which is included entirely, independent of the map file entry.
At this time he was thinking about changing /FontName in the free URW fonts on CTAN
I sincerely hope Walter does not do that. Seems like it would have major backward-compatibility implications.
No, he didn't. It was an idea which came up during the conference dinner, but he changed his mind quite soon. I just metioned it to show that I'm not the only one who sees problems here. Karl, if anyone changes some font names, I suppose you are the first one who will notice this because he will ask you to update the fontname database you maintain. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
Reinhard Kotucha wrote:
The message is just an example. It should be understood by people who do not know what subsetting is. But English is not my native language, feel free to provide better suggestions.
Hans, is this ok for you? Or is it still too crappy?
i can live with one line (but don't expect the average user to understand what subsetting is -)
Usually there is no need to download an entire font. The map files provided by TeX distributions are set up to do subsetting by default. My only concern is that people rely on this and do not notice that they violate against licenses because something happens in the background they are not aware of.
my guess is that no font ever gets embedded completely, since (1) tex does not use the space and (2) no tex encoding uses all slots; maybe pdftex should always subset
Sounds quite straightforward: An asterisk for each font which is included entirely, independent of the map file entry.
indeed Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
"Tomas" == Tomas G Rokicki
writes:
All your points are good, but I clain the "fix" is still an improvement, and for that reason I am leaving it in there.
Yes. It is definitely an improvement and should not be reversed. It seems that pdftex and dvips now behave similar, which also is an advantage. And a quick fix isn't what I want if it has an impact on reliability. But it is something one should keep in mind for future versions.
Perhaps I am naive, but if someone gives me an environment in which there are multiple, and distinctly different, fonts, with the same /FontName, I claim all bets are off. I have encountered this before and it's not a good situation. At this time I simply don't have a solution for a case like this.
You already live in such an environment. At the university we had a Kyocera printer with built in Bitstream fonts. The /Courier had the same problem as the IBM Courier, you couldn't distinguish between a /leftquote and a /rightquote at normal sizes (10pt ... 12pt). In this case you have to download the font. And you must always download Courier if you want your document to be portable. The nasty thing is that people use Courier for printing program code. I prefer cmtt for things like that, anyway. But some people still use Courier.
On the other hand, I do agree that it is better to rename the TeX fonts if we will partially subset them. I believe we should do this (assuming technically we can make it work; I do not know that we cannot, nor do I know of specific issues, but I would not be surprised if this breaks something).
AFAIK, fonts in PostScript files are always global so that they cannot be handled by save/restore or gsave/grestore, but I'm not sure. If this is true, then I do not see any other solution than to rename one of them if an embedded font and a TeX font have the same /FontName but are different. To decide whether two fonts are different it's better to compare their /UniqueIDs rather than their /FontNames. Or probably both.
with to mess with. I do know that I have had in the past substantial problems with just changing the UniqueID of the font; different interpreters were very unhappy with some of the changes I made and I had to back them out. But that's just a technical issue.
That's strange. From the viewpoint of a PS interpreter a UniqueID is an arbitrary number.
Another alternative is to run all included graphics through a companion interpreter that's been configured to only collect information on what characters and what fonts are used (probably by redefining show and a few other operators). But this is another substantial undertaking.
Interesting point. If you only want to use an external interpreter to solve the problems we talked about, it's probably not worth the effort. This could be handled by an external program as well which also fixes %%BoundingBox: (atend). There are some limitations in dvips because it lacks a PS interpreter. For instance, I wrote a script which used dvips -E to convert TeX formulas to eps and then converted them to png. I tried the same with graphics, but that failed because dvips doesn't understand PostScript's scale, translate and rotate operators. If you want to support something like that, it makes sense to think about it. As far as eps-files are concerned, an external program wouldn't be bad. It could check whether the required font exists in texmf, and if this is true, determine the subset, remove the font and add a comment to the eps file which is similar to that what metapost inserts if the prologues variable is not set. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------
participants (6)
-
h h extern
-
Hans Hagen
-
Hartmut Henkel
-
karl@freefriends.org
-
Reinhard Kotucha
-
Tomas G. Rokicki