Here is example with cmb12 and olsl12 fonts. Thank you very much for all your work, Pali. It was easy to apply and confirm that .enc files could be given for bitmap fonts too. Committed to pdftex (r772) and TL (r43519). It'll be in this year's release (pretesting will start next month). Let me know if any problems, of course. --thanks again, karl.

What would be preferred way to test if current running pdftex version supports .enc files for bitmap fonts? \ifnum\pdftexrevision > 17 I guess. With tests for \pdftexversion if you want to be pedantic, although I see no likelihood of that ever changing again. Probably those should be used: http://tug.org/pipermail/pdftex/2016-June/008980.html http://tug.org/pipermail/pdftex/2016-July/009012.html Right, thanks. Too much mail. -k

Dear Pali, (1) If fourth line is commented then output in PDF file looks good, but has no enc vector and no /ToUnicode. (2) If fourth line is uncommented, then font at 60pt in output PDF file looks very very ugly (looks like wrongly rasterized), but has enc vector and /ToUnicode. In the case (1), I see two type3 fonts in the result. In the case (2), I see only one type3 font in the result. Probably the font \fg is a scaled-up one of the font \ff in the case (2). Just a phenomenology. I don't know the reason. Best, Akira

On Sunday 26 March 2017 23:01:20 Karl Berry wrote:

%\pdfmapline{cmr10 <8r.enc} \font\ff=cmr10 \font\fg=cmr10 at 60pt

As Akira described: without the \pdfmapline, there are two different Type3 fonts. I presume that one is constructed from cmr10.600pk and one from cmr10.3600pk.

Yes, something which I found too.

With the \pdfmapline, the PDF output has only one Type3 font. I surmise it is cmr10.600pk geometrically scaled by a factor of 6, hence the extremely visible jaggies. (By the way, you can see the usual bitmap jaggies in all cases if you sufficiently increase the magnification in your PDF viewer, so at least it's clear that bitmaps are correctly being used in all cases.)

Yes, scaling bitmap fonts does not work, but if it is generated for correct DPI, then printed (at paper) looks nice...

In other words, something in your patch is causing pdftex to reuse the first (normal) instance of cmr10 for the second (at 60pt) instance, instead of creating a new instance. However, I'm afraid I have no immediate clue about where to find the problem in the code. It was your patch :), so maybe you'll have a better idea of how to debug? I hope so, because it's not a project I can undertake.

Now I did some investigation, and basically it is not in my patch... It is even documented in pdftex-t.tex Lines containing nothing apart from {\em tfmname} stand for scalable Type~3 fonts. For scalable fonts as Type~1, TrueType and scalable Type~3 font, all the fonts loaded from a \TFM\ at various sizes will be included only once in the \PDF\ output. Thus if a font, let's say \type{csr10}, is described in one of the map files, then it will be treated as scalable. As a result the font source for csr10 will be included only once for \type{csr10}, \type{csr10 at 12pt} etc. So \PDFTEX\ tries to do its best to avoid multiple embedding of identical font sources. Thus vector \PGC\ fonts should be specified as scalable Type~3 in map files like: \starttyping csr10 \stoptyping It doesn't hurt much if a scalable Type~3 font is not given in map files, except that the font source will be embedded into the \PDF\ file multiple times for various sizes, which causes a much larger \PDF\ output. On the other hand if a font in the map files is defined as scalable Type~3 font and its \PGC\ source is not scalable or not available, \PDFTEX\ will use \PK\ fonts instead; the \PDF\ output is still valid but some fonts may look ugly because of the scaled bitmap. But what surprised me is that it is not possible to use this construction, specifying only name of metric file in map line. pdftex in this case show error $ pdftex '\pdfmapline{csr10}\bye' This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdftex) restricted \write18 enabled. entering extended mode pdfTeX warning: pdftex: invalid entry for `csr10': both ps_name and font file missing No pages of output. Transcript written on texput.log. Side effect of my patch is that it allowed to use this construction in case enc file is specified. So I suggest to either update documentation or allow such construction (even without enc file). IIRC just check for that error message "both ps_name and font file missing" needs to be updated, similarly like I did it in my patch for enc file. ==== Anyway, I did deeper investigation and find something. Probably function hasfmentry(f) is used for checking if font f is scalable or not. Specially in function pdf_init_font() in file pdftex.web. So to allow using enc file for PK font which is not scalable we need another syntax in map line which say that particular font is not scalable. Or maybe... another option. Currently pdftex first search for pgc font and then fallback to pk font. It is implemented in function writet3() around t3_open() in file writet3.c. Also documented in pdftex-t.tex If a used font is not present in the map files, first \PDFTEX\ will look for a source with suffix \type{.pgc}, which is a so||called \PGC\ source (\PDF\ Glyph Container) \footnote {This is a text file containing a \PDF\ Type~3 font, created by \METAPOST\ using some utilities by Hans Hagen. In general \PGC\ files can contain whatever is allowed in a \PDF\ page description, which may be used to support fonts that are not available in \METAFONT. \PGC\ fonts are not widely useful, as vector Type~3 fonts are not displayed very well in older versions of Acrobat Reader, but may be more useful when better Type~3 font handling is more common.}. If no \PGC\ source is available, \PDFTEX\ will try to use \PK~fonts as \DVI\ drivers do, creating \PK~fonts on||the||fly if needed. What about splitting specification for PK fonts and PGC fonts in map file and probably make all PK fonts automatically not scalable? As I think bitmap fonts generated for specific DPI is really not scalable. Anyway, is there some script or program which can generate any PGC files? Quick look at google does not find anything, even not any specification for that file. I could probably decode it from pdftex source code... -- Pali Rohár pali.rohar@gmail.com

Reinhard Kotucha wrote:

But nowadays I don't see any reason to care about Type3 fonts or "PDF Glyph Containers" at all. The best solution is to create Type1 fonts from Metafont sources. To be honest, I see little point in creating fonts at all; there are so many superb fonts out there in the real world that creating fonts is (IMHO) just a waste of effort. Of course, this does pre-suppose that one is using XeTeX (or perhaps LuaTeX -- I know very little about the latter), but for all its failings Unicode /*is*/ the future, and the sooner we abandon 8-bit TeX engines for ever the better (again, IMHO). This is in no way meant to diminish Thành's achievements in creating PdfTeX, which was a stunning achievement for its time, but apart from using it for comparison purposes I do not remember the last time I used it in earnest (well, OK, more recently than I used "real" TeX !).

** Phil. -- <signature> Philip Taylor

On 3/27/2017 11:53 PM, Reinhard Kotucha wrote:

On 2017-03-27 at 09:59:34 +0200, Pali Rohár wrote:

...

Anyway, is there some script or program which can generate any PGC files? Quick look at google does not find anything, even not any specification for that file. I could probably decode it from pdftex source code...

AFAIK the "PDF Font Containers" are not officially maintained. They were introduced in order to support development of pdfTeX itself but never supposed to be used by mortal users.

We added that as an experiment as part of Thanh's thesis work. It permitted injection of shapes generated by metapost.

Instead of using Type3 fonts, you get better results if you create Type1 fonts from the Metafont sources.

http://www.tex.ac.uk/FAQ-textrace.html

textrace first used autotrace, later potrace, in order to create Type1 outlines from high-resolution bitmaps created by Metafont. The disadvantage is that the final outlines are not always perferct. I do not know how much time Vladimir Volovich spent on manual tweaking when he created the CM-Super Type1 fonts. On the other hand, Tigran Aivazian converted Yannis Haralambous' Hebrew fonts using textrace for his Bible project in 2006 and the result was excellent. AFAIK he didn't tweak anything manually.

The main problem with textrace is that I don't know whether this program is available anymore. It's not on CTAN, but if it had ever been there, I could check my old TeX Collection CDs/DVDs.

Maybe the better choice nowadays is MetaType1. The Metafont source files are processed by MetaPost and converted to PostScript. The PostScript files are then converted to high-quality Type1 fonts by a bunch of scripts. I assume that MetaType1 is quite reliable because the Latin Modern fonts were created with MetaType1, presumably without manual interaction. After all, MetaType1 is still maintained.

Type3 fonts can contain arbitrary PostScript code. They are just collections of pictures. However, the Type3 font format allows to assign pictures to characters. Even if glyphs are made up of lines and curves, the quality is quite poor. Type1 fonts contain so-called "hints" which provide additional information used when glyphs are fitted to a grid. The hints make sure that all vertical stems of an "m" have the same width, for example.

fwiw: this matters less on modern displays ... i'm not even sure if the lm / gyre have much hinting in them

dvips (and later pdftex) used the Type3 font format in order to allow bitmaps created with Metafont to be inserted into PostScript or PDF files. This was fine at a time when very few Type1 fonts were available.

But nowadays I don't see any reason to care about Type3 fonts or "PDF Glyph Containers" at all. The best solution is to create Type1 fonts from Metafont sources.

it's still interesting to be able to inject arbitrary shapes (with a bit of packaging in actualtext one can even get cut/paste right)

If you are successful, please upload the Type1 fonts to CTAN.

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 3/28/2017 11:46 PM, Pali Rohár wrote:

On Tuesday 28 March 2017 11:27:03 Hans Hagen wrote:

...

On 3/27/2017 11:53 PM, Reinhard Kotucha wrote:

...

On 2017-03-27 at 09:59:34 +0200, Pali Rohár wrote:

...

Anyway, is there some script or program which can generate any PGC files? Quick look at google does not find anything, even not any specification for that file. I could probably decode it from pdftex source code...

AFAIK the "PDF Font Containers" are not officially maintained. They were introduced in order to support development of pdfTeX itself but never supposed to be used by mortal users.

We added that as an experiment as part of Thanh's thesis work. It permitted injection of shapes generated by metapost.

Are there any PGC font files? Or are there any scripts which can generate them (e.g. from metapost output)?

I was not able to find any information about PGC, just that what is in pdftex documentation.

...

...

But nowadays I don't see any reason to care about Type3 fonts or "PDF Glyph Containers" at all. The best solution is to create Type1 fonts from Metafont sources.

it's still interesting to be able to inject arbitrary shapes (with a bit of packaging in actualtext one can even get cut/paste right)

Am I right that simple PDF picture could be stored in PGC container and then used as one font glyph from pdfTeX?

This whole subproject - by thanh, taco and me - was a prelude to outline fonts as replacement for mf bitmap fonts but after a while the lm / gyre font projects made that obsolete. I have a zio with some old test files from 1998 on my machine, perl scripts that I wrote for conversion etc etc. But I don't like distributing code that is that old and might nor work any more. Fonts were defined with: \pdffont <scale> = \pdfscale <number> \pdfglyph <number> <width> <llx> <lly> <urx> <ury> = <pdf literals> \pdfendglyph \pdfglyph <number> <width> <llx> <lly> <urx> <ury> = <pdf literals> \pdfendglyph \pdfendfont (I didn't check if that stil can be done as i haven't used pdftex for a while.) There were more such experiments, like positional support which I first prototyped for dvi, after which Thanh added experimental primitives, and finally we cooked up some definitive solution. Some of the bitmap support in pdftex relates to font expansion and runtime generated font instances but I think that code was removed eventually. But ... these font experiments are 20 year old and I have no time to look into them and see if I can revive the examples. It's also not really a topic for a good-old-times talk or article. As others suggested: just go for outlines and forget about bitmap fonts. (If i'd want bitmap fonts I would probably write this from scratch in LuaTeX using virtual fonts and reuseable pdf objects which is not that hard to do.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Hi Pali, It is even documented in pdftex-t.tex Good reading. I never internalized that piece of information, never having had occasion to care about "scalable Type 3" fonts. Map files: I categorically decline to make any changes whatsoever to map file syntax. PGC files: Hans has replied. I am not aware of any other usage besides his. I'd be ok with introducing a \pdf... boolean that turns off PGC and scalable Type 3, which I gather is what would solve the immediate problem for you. Making such a change at this point in the development process for this year, though ... I don't know. Overall: I have neither energy nor interest in doing anything regarding bitmap fonts. If you can devise a further patch that will improve the situation, then good. If not, I guess the situation will stay as it is. (Well, I'm willing to revert your patch, but I doubt that is what you want.) I realize the documentation as it stands now is not entirely correct, but since the desired outcome and possible changes remain unclear to me, I don't want to tweak it further now. Best, Karl

On Wednesday 29 March 2017 10:53:33 Pali Rohár wrote:

On Tuesday 28 March 2017 22:19:40 Karl Berry wrote:

...

I realize the documentation as it stands now is not entirely correct, but since the desired outcome and possible changes remain unclear to me, I don't want to tweak it further now.

My idea was to enable specifying scalable PK fonts with call \pdfmapline{cmr10} as is already written in pdftex documentation. This should be IIRC very simple and I can prepare patch for it.

But if such support as written in pdftex documentation is not something which should be enabled in pdftex, then removing those parts from documentation should be done.

So pdftex maintainers/developers should decide for one those steps.

Hi Karl! I found out that support for those scalable PK fonts broke in pdfTeX version 1.40.0 by svn revision number 77. Looks like version before they worked... And as patch is really simple and small for enabling scalable PK fonts, I'm sending it in attachment. There is just too strict check in check_fm_entry() and one missing check for NULL dereference. Patch was generated against svn://tug.org/pdftex/branches/stable revision 775. -- Pali Rohár pali.rohar@gmail.com

On 3/30/2017 1:58 AM, Karl Berry wrote:

I believe the original idea of scalable Type 3 was that the font code itself would do the scaling to different sizes; that's why the font only had to be included once. Like a Type 1. But since the demise of PGC et al., that was no longer operative.

It might even refer to the thesis-related feature of automatic generated expanded versions (when doing hz expansion) which was afaik removed later for bitmaps.

To sum up, I think the current behavior is good, and I should change the manual to get rid of PGC stuff, get rid of the phrase "scalable Type 3", and explain the current behavior.

Yes, unless in some appendix you want to preserve history ... but anyway it really makes no sense to keep prc around (btw, I rmember lots of disucssions also with people from adobe about these type 3 quality issues, because at that time type 3 rendering was not that good. It were the years that we started with different method for outputting rules depending on size thresholds and what acrobat liked most). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Dear Pali,

- } else + } else if (is_std_t1font(fm)) set_type1(fm); /* assume a builtin font is Type1 */

Installed in r43645. Many thanks. Best, Akira

On Thursday 30 March 2017 23:53:10 Karl Berry wrote:

Previous (-) line caused that every type3 font was marked as type1.

Marked where, how?

In fm structure (not in output pdf). And then it is checked in check_fm_entry().

- } else + } else if (is_std_t1font(fm))

This alters the logic. Now there is no final fallback case. It looks dangerous.

Previously (-) everything fallback was marked as type1, even those PK fonts (which are type3). Which is wrong. Better fallback mechanism is to introduce new flag for PK/type3 fonts like I did in new patch for \pdfpkscalable.

Now is cmr10 really marked as scalable and included in output PDF only once (for cmr10 and also for cmr10 at 60pt).

But that's not what we want.

Without modification of pdftex.web it is not possible. Changing meaning of scalability of PK fonts needs to fix hasfmentry() usage by new function (e.g. isscalable()) like I did in in patch \pdfpkscalable. Note that without above "+ } else if (is_std_t1font(fm))" line (which I forgot to include into my previous patch) all PK/type3 fonts were ignored by pdftex in check_fm_entry() because they were treated as type1 (which was wrong).

Yes, I understand that idea in same way.

Oh, you did reply, sorry. Lost in my mail.

I'm going to play with PGC files as I think it still could be useful for ability to include any PDF shape into font file...

Fine, but pdftex is no longer the place to do experiments. We must emphasize stability above all with pdftex. I suggest playing in LuaTeX, where you can do all this stuff and a whole lot more at the Lua level ...

I mean to play with PGC files without modification of pdftex sources. Just use what is currently supported by pdftex and see what happens. -- Pali Rohár pali.rohar@gmail.com

On Thursday 30 March 2017 16:40:19 Karl Berry wrote:

In fm structure (not in output pdf).

And is there any way to discern this problem from the behavior of the program, or the output?

Yes, there is. If you revert that patch "+ } else if (is_std_t1font(fm))" then specified PK font with enc file via \pdfmapline{} will be ignored, pdftex fallback from \pdfmapline{} definition to PK font *without* any enc file. So in result PDF file \ToUnicode entry would be missing and enc file in \pdfmapline{} ignored.

Better fallback mechanism

My point is that the patch replaced the fallback else with a conditional else, so now there is no fallback. That is not good.

It is really needed to call set_truetype() or set_opentype() or set_type1()? Seems that no. All code tests if is_truetype(), is_opentype() or is_type1(). And setting type1 for PK/type3 font is incorrect and just cause dropping all PK/type3 fonts as they do not have (for obvious reason) specified PS font basename. What is possible is to introduce set_type3() and is_type3() macros and then set last fallback to set_type3().

is to introduce new flag for PK/type3 fonts like I did in new patch for \pdfpkscalable.

I don't want to support that new primitive, in case that's not obvious by now. -k

-- Pali Rohár pali.rohar@gmail.com