XPost: comp.text.tex
ken <
ken@spamcop.net> wrote:
In article <1591312531.bystand@zzo38computer.org>, news@zzo38computer.org.invalid says...
I have some questions about use of TeX with PostScript. One of my
questions is if there is a way to automatically decide which METAFONT
mode is needed based on the contents of the page device dictionary?
I don't know what 'METAFONT mode' means, it doesn't have any meaning in PostScript.
OK, perhaps it will be helpful to explain it, I suppose.
And what is 'it' ?
The METAFONT mode, of course. METAFONT modes are just names, although they
are used to compile fonts for a specific printer, and each METAFONT mode defines the following parameters (in addition to some others which are not relevant to PostScript, that I am not mentioning here):
* The resolution (already seen in the page device dictionary).
* A "blacker" parameter, to correct stems and so on for devices which
would otherwise make them too light.
* A "fillin" parameter, to correct the darkness of diagonal lines.
* A "o_correction" parameter, to "overshoot" curves beyond the baseline
and x-height, such as that of the letter "o". They say this causes it to
look better at high resolutions, while low resolutions should avoid this.
For example, the METAFONT mode for Xerox 8790 or 4045 (at 600dpi) uses blacker=1, fillin=0.1, and o_correction=0.9. Not having worked with this
many printers, I don't know it exactly, although I should want to ensure
high quality output for any printer, if possible. (There are also METAFONT modes for printers with a much higher resolution than that, too.)
(Also, to clarify: This PostScript code is meant to run on the computer,
not on the printer. This allows it to access external files (such as the
font files, and external files for diagrams), to use the fill level 3 PostScript features, to use Ghostscript features, etc. You would then
rasterize it and send it to the printer. If you do have a PostScript
printer, you could use Ghostscript's PostScript output mode to convert
the output of the PostScript program into level 2 PostScript.)
Perhaps I can also mention that these fonts are bitmap fonts; METAFONT
compiles a vector description of the font (using a complete programming language) into a bitmap font, with hinting, with the parameters mentioned,
with parameters specific to the font (so that you can get many styles of
text just by adjusting the parameters), and with a full programming
language, into the font bitmaps and a font metric file.
Although most users seem not to want bitmap fonts, I am one of the users
who does want to use bitmap fonts. (Bitmap fonts probably are not useful
if you want PDF output, but in my case, PDF isn't what I wanted.)
I'm afraid I really don't know what it is you are actually asking. As
luser droog said perhaps you'll have more luck with a TeX news group, I
can't see where PostScript has any bearing on your explanation or
question.
As I previously explained, I already did that (I cross-posted). But where PostScript has any bearing on the question is the PostScript page device dictionary, as I mentioned. So, in other words, to answer my question
would probably require a knowledge of both METAFONT (which is usually used
with TeX, although it is actually a separate prorgam) and PostScript.
If my question has no answer, that is fine; I can just make it manually specified only; although it may be good to figure it out automatically.
The reason I am using PostScript at all is mainly in order to include
diagrams in the document; those would presumably be written using
PostScript code. (It may also be helpful to embed PostScript code in the document to do other stuff such as setting colours, changing how the rest
of the DVI file will be processed, etc. Your PostScript code for the
diagram might also be passed parameters from TeX, such as the amount of stretching, in case your diagram includes parts which should be vertically stretched, too. If I am making a document without diagrams, then I would
just use dvipbm instead; no need to deal with PostScript.)
I prefer to avoid PDF; DVI is just a better format in many ways, and then another program would rasterize the DVI file; this could be done using a program written in C, Pascal, etc. However, PostScript is still good for diagrams and such thing like that, so instead of using C, I am considering
to use PostScript to implement this rasterization. So, DVI should be used
for the main text of the document, and PostScript for diagrams (with the PostScript code embedded in the DVI file; if they are external then you
can just write something like "(fig1.ps) run" and that will cause it to
execute the PostScript file fig1.ps when that point is reached).
Rasterizing a DVI file does involve more than just fonts; it also involves rounding pixel positions and dealing with drifting properly. See DVItype
for details of this algorithm (implemented in Pascal).
--
This signature intentionally left blank.
(But if it has these words, then actually it isn't blank, isn't it?)
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)