Re: [NTG-context] Why uses Context 8r encoding used instead of the specified ec encoding?
Hans Hagen wrote:
\def\loadmapline
{\dodoubleempty\loadmapline}
\def\loadmapline[#1][#2]%
{\loadallfontmapfiles % ! ! !
\doloadmapline{#1}{#2}}
I'd be surprised if that worked. The second \def overwrites the first.
Christopher
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] Why uses Context 8r encoding used instead of the specified ec encoding?
Christopher Creutzig wrote:
Hans Hagen wrote:
\def\loadmapline
{\dodoubleempty\loadmapline}
\def\loadmapline[#1][#2]%
{\loadallfontmapfiles % ! ! !
\doloadmapline{#1}{#2}}
I'd be surprised if that worked. The second \def overwrites the first.
it did when i tested it with two args -)
\def\loadmapline
{\dodoubleempty\dodoloadmapline}
\def\dodoloadmapline[#1][#2]%
{\loadallfontmapfiles % ! ! !
\doloadmapline{#1}{#2}} % special
-
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
-
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] Why uses Context 8r encoding used instead of the specified ec encoding?
Hi Stefan,
Stefan Wachter wrote:
Hi all!
Fonts are driving my crazy! I have the following document that clearly
states that the font encoding should be ec. Yet, somewhere behind the
scenes the ec-encoded font uhvr8t is mapped into the 8r-encoded font
uhvr8r.
Can someone reveal this deep secret?
The uhvr8t font is a virtual font, probably created by fontinst.
(A virtual font is a font built up from other fonts to create something
that looks like a single font to TeX. This allows the font package
creator to fill holes in the original font and add extra accented
characters etc. You can think of it as an unexpanded macro)
A 'normal' TeX that outputs DVI really would only use the font metrics
uhvr8t.tfm, and later, dvips expands the font into it's constituent
parts while creating the PostScript output. At that time, dvips will
read psfonts.map, which should have lines for all of the possible
constituent fonts so that the actual fonts can be embedded in the PS
file for printing. If you would have run Context in a DVI-creating
mode, this is what would have happened.
For pdftex, that font de-virtualization step has to be done right
away because there is no separate 'dvipdf' program, so pdtex is
a somewhat like a two-stage rocket: tex - dvi - pdf, combined in
one executable.
It is that second (post-processing) step that uses the uhvr8r font
(and the mapline associated with it), but while typesetting ConTeXt
*does* use the requested 8t font. You can be verify that by running
\showfont[Sans].
Greetings, Taco
Best regards,
--Stefan
PS: The pdfmapline instruction cause the uhvr8r font not to be embedded.
Doing so proves that Context really uses the uhvr8r font and not the
uhvr8t font.
\enableregime[il1]
\setupencoding[default=ec]
\setupoutput[pdftex]
\usetypescriptfile[pdf-typescript.tex]
\usetypescript[pdf]
\setupbodyfont[MyHelvetica,sans,20pt]
\setupheadertexts[]
\pdfoptionpdfminorversion 4
\starttext
\pdfmapline{=uhvr8r Helvetica TeXBase1Encoding ReEncodeFont 8r.enc}
This is a test.
\stoptext
With the typescriptfile pdf-typescript.tex:
\starttypescript [sans] [xhelvetica] [name]
\writestatus{x}{y}
\definefontsynonym [Sans][uhvr8t] [encoding=ec]
\definefontsynonym [SansBold][uhvb8t] [encoding=ec]
\definefontsynonym [SansItalic] [uhvro8t] [encoding=ec]
\definefontsynonym [SansSlanted] [uhvro8t] [encoding=ec]
\definefontsynonym [SansBoldItalic] [uhvbo8t] [encoding=ec]
\definefontsynonym [SansBoldSlanted] [uhvbo8t] [encoding=ec]
\definefontsynonym [SansCaps][uhvr8t] [encoding=ec]
\stoptypescript
\starttypescript [pdf]
\definetypeface [MyHelvetica] [ss] [sans] [xhelvetica] [default]
[encoding=ec]
\stoptypescript
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] Why uses Context 8r encoding used instead of the specified ec encoding?
Taco Hoekwater wrote: Can someone reveal this deep secret? The uhvr8t font is a virtual font, probably created by fontinst. Can we create a section in the wiki where such nice explanations can go into? Something: some details about how tex works - 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 - ___ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
Re: [NTG-context] Why uses Context 8r encoding used instead of the specified ec encoding?
Stefan Wachter wrote:
Fonts are driving my crazy! I have the following document that clearly
states that the font encoding should be ec. Yet, somewhere behind the
scenes the ec-encoded font uhvr8t is mapped into the 8r-encoded font
uhvr8r.
\starttext
\def\loadmapline
{\dodoubleempty\loadmapline}
\def\loadmapline[#1][#2]%
{\loadallfontmapfiles % ! ! !
\doloadmapline{#1}{#2}}
\loadmapline[uhvr8r Helvetica TeXBase1Encoding ReEncodeFont 8r.enc]
the map files are flushed at certain moments, and in your case after th
emapline; has to do with older pdftex's and prefered places of flushing;
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
-
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
[NTG-context] Why uses Context 8r encoding used instead of the specified ec encoding?
Hi all!
Fonts are driving my crazy! I have the following document that clearly
states that the font encoding should be ec. Yet, somewhere behind the
scenes the ec-encoded font uhvr8t is mapped into the 8r-encoded font
uhvr8r.
Can someone reveal this deep secret?
Best regards,
--Stefan
PS: The pdfmapline instruction cause the uhvr8r font not to be embedded.
Doing so proves that Context really uses the uhvr8r font and not the
uhvr8t font.
\enableregime[il1]
\setupencoding[default=ec]
\setupoutput[pdftex]
\usetypescriptfile[pdf-typescript.tex]
\usetypescript[pdf]
\setupbodyfont[MyHelvetica,sans,20pt]
\setupheadertexts[]
\pdfoptionpdfminorversion 4
\starttext
\pdfmapline{=uhvr8r Helvetica TeXBase1Encoding ReEncodeFont 8r.enc}
This is a test.
\stoptext
With the typescriptfile pdf-typescript.tex:
\starttypescript [sans] [xhelvetica] [name]
\writestatus{x}{y}
\definefontsynonym [Sans][uhvr8t] [encoding=ec]
\definefontsynonym [SansBold][uhvb8t] [encoding=ec]
\definefontsynonym [SansItalic] [uhvro8t] [encoding=ec]
\definefontsynonym [SansSlanted] [uhvro8t] [encoding=ec]
\definefontsynonym [SansBoldItalic] [uhvbo8t] [encoding=ec]
\definefontsynonym [SansBoldSlanted] [uhvbo8t] [encoding=ec]
\definefontsynonym [SansCaps][uhvr8t] [encoding=ec]
\stoptypescript
\starttypescript [pdf]
\definetypeface [MyHelvetica] [ss] [sans] [xhelvetica] [default]
[encoding=ec]
\stoptypescript
___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context
