copyfont and font features
This comes from a tex.sx question https://tex.stackexchange.com/questions/338942/cancellation-of-color-fontspe... The primitive \copyfont looses with open type fonts all font features: \starttext \font\testa={Arial:mode=node;script=latn;language=DFLT;+tlig;+smcp;} {\testa abc -- } normal \copyfont\testb\testa {\testb abc -- } normal \stoptext As one can see \testb has neither ligatures nor it is in small caps. Is this a bug or to be expected? If the second: Is there in the fontloader a replacement which can be used to copy fonts? -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 11/16/2016 6:17 PM, Ulrike Fischer wrote:
This comes from a tex.sx question https://tex.stackexchange.com/questions/338942/cancellation-of-color-fontspe...
The primitive \copyfont looses with open type fonts all font features:
\starttext
\font\testa={Arial:mode=node;script=latn;language=DFLT;+tlig;+smcp;} {\testa abc -- } normal
\copyfont\testb\testa
{\testb abc -- } normal
\stoptext
As one can see \testb has neither ligatures nor it is in small caps. Is this a bug or to be expected?
It's to be expected as \copyfont makes a copy at the tfm level. One can just use \let\testb\testa instead. Information related to fonts at the lua end is not known to \copyfont.
If the second: Is there in the fontloader a replacement which can be used to copy fonts?
I think the \copyfont primitive was introduced in pdftex as a kind of speedup (not that there was any speed to gain) or convenience (saves a define) for applying protrusion and other tricks (luatex dropped most of them) to a font. So, the primitive is only there for compatibility reasons. It makes no sense to have a replacement (at least I can't think of a case that can't be handled already). Just define the font again. 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 -----------------------------------------------------------------
Am Thu, 17 Nov 2016 09:46:26 +0100 schrieb Hans Hagen:
On 11/16/2016 6:17 PM, Ulrike Fischer wrote:
This comes from a tex.sx question https://tex.stackexchange.com/questions/338942/cancellation-of-color-fontspe...
The primitive \copyfont looses with open type fonts all font features:
\starttext
\font\testa={Arial:mode=node;script=latn;language=DFLT;+tlig;+smcp;} {\testa abc -- } normal
\copyfont\testb\testa
{\testb abc -- } normal
\stoptext
As one can see \testb has neither ligatures nor it is in small caps. Is this a bug or to be expected?
It's to be expected as \copyfont makes a copy at the tfm level. One can just use
\let\testb\testa
instead.
Simply using \let doesn't work when you want locally a different expansion behaviour: ! error: (font expansion): font has been expanded with different stretch limit. (with pdflatex + lualatex), that's imho the reason why microtype copies the fonts.
It makes no sense to have a replacement (at least I can't think of a case that can't be handled already). Just define the font again.
The question is if microtype can easily retrieve the current font features and if it will slow down the code much if it has to redefine fonts again and again. -- Ulrike Fischer http://www.troubleshooting-tex.de/
On 11/17/2016 11:02 AM, Ulrike Fischer wrote:
Am Thu, 17 Nov 2016 09:46:26 +0100 schrieb Hans Hagen:
On 11/16/2016 6:17 PM, Ulrike Fischer wrote:
This comes from a tex.sx question https://tex.stackexchange.com/questions/338942/cancellation-of-color-fontspe...
The primitive \copyfont looses with open type fonts all font features:
\starttext
\font\testa={Arial:mode=node;script=latn;language=DFLT;+tlig;+smcp;} {\testa abc -- } normal
\copyfont\testb\testa
{\testb abc -- } normal
\stoptext
As one can see \testb has neither ligatures nor it is in small caps. Is this a bug or to be expected?
It's to be expected as \copyfont makes a copy at the tfm level. One can just use
\let\testb\testa
instead.
Simply using \let doesn't work when you want locally a different expansion behaviour:
! error: (font expansion): font has been expanded with different stretch limit.
(with pdflatex + lualatex), that's imho the reason why microtype copies the fonts.
in fact that is also the case with pdftex: afaik expansion and protrusion values are global and once a font is used they get frozen in luatex (at least the lua font loader) one can set the expansion at definition time (which is more natural but not possible in pdftex)
It makes no sense to have a replacement (at least I can't think of a case that can't be handled already). Just define the font again.
The question is if microtype can easily retrieve the current font features and if it will slow down the code much if it has to redefine fonts again and again.
that's a matter of implementation (because expansion slows down processing anyway, defining an extra font is hardly the bottleneck - just some milliseconds) 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 -----------------------------------------------------------------
Am Thu, 17 Nov 2016 13:07:22 +0100 schrieb Hans Hagen:
Simply using \let doesn't work when you want locally a different expansion behaviour:
! error: (font expansion): font has been expanded with different stretch limit.
(with pdflatex + lualatex), that's imho the reason why microtype copies the fonts.
in fact that is also the case with pdftex: afaik expansion and protrusion values are global and once a font is used they get frozen
Yes, exactly.
in luatex (at least the lua font loader) one can set the expansion at definition time (which is more natural but not possible in pdftex)
Yes, but I understand that -- if possible -- microtype prefers code that works in pdftex *and* luatex.
The question is if microtype can easily retrieve the current font features and if it will slow down the code much if it has to redefine fonts again and again.
that's a matter of implementation
Yes, the maintainer of microtype has been informed about the problem and can now look for a solution ... -- Ulrike Fischer http://www.troubleshooting-tex.de/
participants (2)
-
Hans Hagen -
Ulrike Fischer