Re: [NTG-context] Palatino patch for the current ConTeXt version
On 11/27/2013 12:40 AM, Jan Tosovsky wrote:
On 2013-11-17 Hans Hagen wrote:
On 11/17/2013 12:23 PM, honyk wrote:
Hello Everyone,
I am trying to fix a Palatino small caps issue using the procedure
explained here:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
That fix seems to be obsolete nowadays and returning errors.
there are several ways to apply patches runtime, see *.lfg files (and
also fonts-mkiv.pdf)
1) I've created a sample LFG file
2) placed it into the folder where other LFG files are stored
3) removed pala.tma and pala.tmc files from the cache
4) triggered the generating
My pala.lfg file seems to be ignored:
return {
name = pala,
comment = Switching the small capped 'i' to a dotless variant in
Palatino Linotype.,
remapping = {
tounicode = true,
unicodes = {
[i.sc] = 983201,
},
},
}
1) How the LFG file is matched with the font? Is it via the 'name'
parameter, pala in my case? Does that name equals to the file title
without an extension or something else?
2) Should I see that comment in the log or is it just a remark for editors?
3) Can I emulate this patch via direct editing of pala.tma file? When I
change the 'unicodes' value there, it has no impact on generating (nothing
changes in the output).
you have to load them ... see fonts-mkiv.pdf
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] bug in beta: \tab results in text overlap
On 11/22/2013 4:34 PM, Hans Hagen wrote:
The problem, is/was that mixed columns had not yet mark
synchronization enabled. I uploaded a new beta. In the process I also
made marks a bit more restrictive but it might have (yet unknown) side
effects.
Hans, I tried the beta of 2013.11.26, and as mentioned in a previous
email, it fixes the \getmarking problem pretty well. However the same
beta has a fatal problem for us: lists using \tab are now broken.
MWE:
\starttext
\tab{AC}Autonomous Community\par
\tab{\it alt.}alternate name for\par
\stoptext
In the TeX Live 2013 version of mkiv, this gives us a nice table with
the headword separated from the definition.
In the beta, the headword and the definition start at the same
horizontal position, and overlap each other.
We use these lists in the context of mixedcolumns, but the overlap
behavior occurs regardless of mixedcolumns.
Any help would be appreciated. If we can't fix or work around this
problem, we may have to abandon the beta and go back to TeX Live 2013,
which means our page header guide words would be incorrect.
Lars
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] bug in beta: \tab results in text overlap
On 11/27/2013 11:08 AM, Lars Huttar wrote:
I tried the beta of 2013.11.26, and as mentioned in a previous
email, it fixes the \getmarking problem pretty well. However the same
beta has a fatal problem for us: lists using \tab are now broken.
MWE:
\starttext
\tab{AC}Autonomous Community\par
\tab{\it alt.}alternate name for\par
\stoptext
In the TeX Live 2013 version of mkiv, this gives us a nice table with
the headword separated from the definition.
In the beta, the headword and the definition start at the same
horizontal position, and overlap each other.
We use these lists in the context of mixedcolumns, but the overlap
behavior occurs regardless of mixedcolumns.
Any help would be appreciated. If we can't fix or work around this
problem, we may have to abandon the beta and go back to TeX Live 2013,
which means our page header guide words would be incorrect.
Well, it's probably not quite that fatal for our project, because it
looks like the \definedescription mechanism can be used to replace \tab,
and does not suffer from the same problem in the beta.
Nevertheless I thought someone would like to know that \tab has stopped
working, so it can be fixed (or documented as obsolete, in favor of
\definedescription).
Lars
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] ctxluacode inside bTABLE
I try make a table with some random numbers but I found a problem with this
code:
\starttext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\bTABLE
\bTR\bTD Distance (cm) \eTD\bTD $\Delta t$ (s) \eTD\eTR
\bTR\bTD[nr=3] \ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\eTD\bTD t1 \eTD\eTR
\bTR\bTD t2 \eTD\eTR
\bTR\bTD t3 \eTD\eTR
\eTABLE
\stoptext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;} don't work
inside the bTABLE environment.
Thanks in advance.
Jorge
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] ctxluacode inside bTABLE
Hi Jorge,
···date: 2013-11-27, Wednesday···from: DesdeChaves···
I try make a table with some random numbers but I found a problem with this
code:
\starttext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\bTABLE
\bTR\bTD Distance (cm) \eTD\bTD $\Delta t$ (s) \eTD\eTR
\bTR\bTD[nr=3] \ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\eTD\bTD t1 \eTD\eTR
\bTR\bTD t2 \eTD\eTR
\bTR\bTD t3 \eTD\eTR
\eTABLE
\stoptext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;} don't work
inside the bTABLE environment.
just wrap the code in a macro. Lua code needs a different catcode
regime and expansion rules that don’t cooperate well with the
table scanner. E.g.
\startluacode
local mathrandom = math.random
local context= context
document.get_random_number = function ()
context (%0.1f, mathrandom (400, 600) / 10)
end
\stopluacode
\def \getrandomnumber {\ctxluacode {document.get_random_number ()}}
\starttext
\bTABLE
\bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR
\bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD \eTR
\bTR \bTD t2 \eTD \eTR
\bTR \bTD t3 \eTD \eTR
\eTABLE
\stoptext
Hth,
Philipp
pgpVMnxrZGPeS.pgp
Description: PGP signature
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] ctxluacode inside bTABLE
Is there a way to pass arguments to getrandomnumber() function?
\startluacode
local mathrandom = math.random
local context= context
document.get_random_number = function (min,max,delta)
context (%0.1f, mathrandom (min, max) / decimal)
end
\stopluacode
\def \getrandomnumber#1#2#3 {\ctxluacode {document.get_random_number
(#1,#2,#3)}}
\starttext
\bTABLE
\bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR
\bTR \bTD[nr=3] \getrandomnumber{34,56,10} \eTD \bTD t1
\eTD \eTR
\bTR \bTD t2 \eTD \eTR
\bTR \bTD t3 \eTD \eTR
\eTABLE
\stoptext
2013/11/27 Philipp Gesang philipp.ges...@alumni.uni-heidelberg.de
Hi Jorge,
···date: 2013-11-27, Wednesday···from: DesdeChaves···
I try make a table with some random numbers but I found a problem with
this
code:
\starttext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\bTABLE
\bTR\bTD Distance (cm) \eTD\bTD $\Delta t$ (s) \eTD\eTR
\bTR\bTD[nr=3] \ctxluacode{v=math.random(400,600)/10;context(%0.1f,v)
;}
\eTD\bTD t1 \eTD\eTR
\bTR\bTD t2 \eTD\eTR
\bTR\bTD t3 \eTD\eTR
\eTABLE
\stoptext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;} don't work
inside the bTABLE environment.
just wrap the code in a macro. Lua code needs a different catcode
regime and expansion rules that don’t cooperate well with the
table scanner. E.g.
\startluacode
local mathrandom = math.random
local context= context
document.get_random_number = function ()
context (%0.1f, mathrandom (400, 600) / 10)
end
\stopluacode
\def \getrandomnumber {\ctxluacode {document.get_random_number ()}}
\starttext
\bTABLE
\bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR
\bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD \eTR
\bTR \bTD t2 \eTD \eTR
\bTR \bTD t3 \eTD \eTR
\eTABLE
\stoptext
Hth,
Philipp
___
If your question is of interest to others as well, please add an entry to
the Wiki!
maillist : ntg-context@ntg.nl /
http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
--
Atentamente
DesdeChaves
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] ctxluacode inside bTABLE
···date: 2013-11-27, Wednesday···from: DesdeChaves···
Solved
\getrandomnumber{36}{56}{10}
Or define it monadic:
\def \getrandomnumber #1{\ctxluacode {document.get_random_number (#1)}}
Now you can use your original syntax:
\getrandomnumber {23, 42, 10}
Though it blurs the line between TeX and Lua code.
Best,
Philipp
2013/11/27 DesdeChaves desdecha...@gmail.com
Is there a way to pass arguments to getrandomnumber() function?
\startluacode
local mathrandom = math.random
local context= context
document.get_random_number = function (min,max,delta)
context (%0.1f, mathrandom (min, max) / decimal)
end
\stopluacode
\def \getrandomnumber#1#2#3 {\ctxluacode {document.get_random_number
(#1,#2,#3)}}
\starttext
\bTABLE
\bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD \eTR
\bTR \bTD[nr=3] \getrandomnumber{34,56,10} \eTD \bTD t1
\eTD \eTR
\bTR \bTD t2 \eTD \eTR
\bTR \bTD t3 \eTD \eTR
\eTABLE
\stoptext
2013/11/27 Philipp Gesang philipp.ges...@alumni.uni-heidelberg.de
Hi Jorge,
···date: 2013-11-27, Wednesday···from: DesdeChaves···
I try make a table with some random numbers but I found a problem with
this
code:
\starttext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\bTABLE
\bTR\bTD Distance (cm) \eTD\bTD $\Delta t$ (s) \eTD\eTR
\bTR\bTD[nr=3]
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;}
\eTD\bTD t1 \eTD\eTR
\bTR\bTD t2 \eTD\eTR
\bTR\bTD t3 \eTD\eTR
\eTABLE
\stoptext
\ctxluacode{v=math.random(400,600)/10;context(%0.1f,v) ;} don't work
inside the bTABLE environment.
just wrap the code in a macro. Lua code needs a different catcode
regime and expansion rules that don’t cooperate well with the
table scanner. E.g.
\startluacode
local mathrandom = math.random
local context= context
document.get_random_number = function ()
context (%0.1f, mathrandom (400, 600) / 10)
end
\stopluacode
\def \getrandomnumber {\ctxluacode {document.get_random_number ()}}
\starttext
\bTABLE
\bTR \bTD Distance (cm) \eTD \bTD $\Delta t$ (s) \eTD
\eTR
\bTR \bTD[nr=3] \getrandomnumber \eTD \bTD t1 \eTD
\eTR
\bTR \bTD t2 \eTD
\eTR
\bTR \bTD t3 \eTD
\eTR
\eTABLE
\stoptext
Hth,
Philipp
___
If your question is of interest to others as well, please add an entry to
the Wiki!
maillist : ntg-context@ntg.nl /
http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
--
Atentamente
DesdeChaves
--
Atentamente
DesdeChaves
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
pgplurss59jv8.pgp
Description: PGP signature
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
[NTG-context] [***SPAM***] Incorrect internal font processing
Dear All, during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) (2) - this is a composite character which consist of dotlessi.smcp and dot. The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. Regards, Jan ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 11/27/2013 8:44 PM, Jan Tosovsky wrote: Dear All, during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) (2) - this is a composite character which consist of dotlessi.smcp and dot. The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. the font pala.ttf has two entries i.sc and i see no reference to *.smcp (mtxrun --script --save pala.ttf) naming of glyphs is somewhat fuzzy and not always consistentent in fonts but i fear there is not much we can do here (apart from using palatino nova instead) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Palatino patch for the current ConTeXt version
On 2013-11-27 Hans Hagen wrote:
On 11/27/2013 12:40 AM, Jan Tosovsky wrote:
On 2013-11-17 Hans Hagen wrote:
On 11/17/2013 12:23 PM, honyk wrote:
Hello Everyone,
I am trying to fix a Palatino small caps issue using the procedure
explained here:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
That fix seems to be obsolete nowadays and returning errors.
there are several ways to apply patches runtime, see *.lfg files
(and also fonts-mkiv.pdf)
1) I've created a sample LFG file
2) placed it into the folder where other LFG files are stored
3) removed pala.tma and pala.tmc files from the cache
4) triggered the generating
My pala.lfg file seems to be ignored:
return {
name = pala,
comment = Switching the small capped 'i' to a dotless variant
in Palatino Linotype.,
remapping = {
tounicode = true,
unicodes = {
[i.sc] = 983201,
},
},
}
you have to load them ... see fonts-mkiv.pdf
Thanks, I got it. Two next steps are required and one turned out as
redundant.
1) Create a sample LFG file
2) Place it into the folder where other LFG files are stored
3) NEW! Execute 'mtxrun --generate' command to include newly added LFG file
into a file database
4) NEW! Specify a new font feature referencing to this goodie:
\definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes]
\definefontfamily[mainface][rm][Palatino
Linotype][features={default,quality,dotlessi}]
5) Trigger the generating
It does something, but not what I need :-)
My MWE:
\definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes]
\definefontfamily[palatino][rm][Palatino
Linotype][features={default,quality,dotlessi}]
\setupbodyfont[palatino]
\starttext
Athenians \sc{Athenians}
\stoptext
This LFG core settings:
unicodes = {
[a.sc] = 97, (1)
[b.sc] = 983261, (2)
},
(1) replaces all small 'a' into small caps variants - just for testing
purposes
(2) doesn't replace small caps 'i' to small caps 'b', but when small caps
text is selected, b is copied into the clipboard - so some replacement is
performed, but incomplete.
Maybe other tables need to be tweaked as well...
Has anybody any experience with this?
Thanks, Jan
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 2013-11-27 Hans Hagen wrote: On 11/27/2013 8:44 PM, Jan Tosovsky wrote: during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) (2) - this is a composite character which consist of dotlessi.smcp and dot. The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. the font pala.ttf has two entries i.sc and i see no reference to *.smcp The version of my Palatino is 5.0 (I run on Win7) It is located at c:/windows/fonts/pala.ttf There is no 'i.sc' glyph available according to the font software, only those .smcp, listed in the smcp6 table. As there are only .sc names in the TMA file, I suppose there is some kind of name normalization. But not very precise... (mtxrun --script --save pala.ttf) This returns an error: c:/windows/fonts/pala.ttf:1: unexpected symbol Jan ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Palatino patch for the current ConTeXt version
On 11/27/2013 9:16 PM, Jan Tosovsky wrote:
On 2013-11-27 Hans Hagen wrote:
On 11/27/2013 12:40 AM, Jan Tosovsky wrote:
On 2013-11-17 Hans Hagen wrote:
On 11/17/2013 12:23 PM, honyk wrote:
Hello Everyone,
I am trying to fix a Palatino small caps issue using the procedure
explained here:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
That fix seems to be obsolete nowadays and returning errors.
there are several ways to apply patches runtime, see *.lfg files
(and also fonts-mkiv.pdf)
1) I've created a sample LFG file
2) placed it into the folder where other LFG files are stored
3) removed pala.tma and pala.tmc files from the cache
4) triggered the generating
My pala.lfg file seems to be ignored:
return {
name = pala,
comment = Switching the small capped 'i' to a dotless variant
in Palatino Linotype.,
remapping = {
tounicode = true,
unicodes = {
[i.sc] = 983201,
},
},
}
you have to load them ... see fonts-mkiv.pdf
Thanks, I got it. Two next steps are required and one turned out as
redundant.
1) Create a sample LFG file
2) Place it into the folder where other LFG files are stored
3) NEW! Execute 'mtxrun --generate' command to include newly added LFG file
into a file database
4) NEW! Specify a new font feature referencing to this goodie:
\definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes]
\definefontfamily[mainface][rm][Palatino
Linotype][features={default,quality,dotlessi}]
5) Trigger the generating
It does something, but not what I need :-)
My MWE:
\definefontfeature[dotlessi][mode=base,goodies=pala,unicoding=yes]
\definefontfamily[palatino][rm][Palatino
Linotype][features={default,quality,dotlessi}]
\setupbodyfont[palatino]
\starttext
Athenians \sc{Athenians}
\stoptext
This LFG core settings:
unicodes = {
[a.sc] = 97, (1)
[b.sc] = 983261, (2)
},
(1) replaces all small 'a' into small caps variants - just for testing
purposes
(2) doesn't replace small caps 'i' to small caps 'b', but when small caps
text is selected, b is copied into the clipboard - so some replacement is
performed, but incomplete.
Maybe other tables need to be tweaked as well...
Has anybody any experience with this?
this mechanism assumes that the shapes match the one that unicode
expects so the (default) tounicode is used ... originally this features
was meant for fonts with a faulty mapping (some dingbat fonts have that)
Hans
--
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 11/27/2013 9:53 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 8:44 PM, Jan Tosovsky wrote: during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) (2) - this is a composite character which consist of dotlessi.smcp and dot. The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. the font pala.ttf has two entries i.sc and i see no reference to *.smcp The version of my Palatino is 5.0 (I run on Win7) It is located at c:/windows/fonts/pala.ttf i checked on windows 8 There is no 'i.sc' glyph available according to the font software, only those .smcp, listed in the smcp6 table. As there are only .sc names in the TMA file, I suppose there is some kind of name normalization. But not very precise... (mtxrun --script --save pala.ttf) mtxrun --script font --save pala.ttf This returns an error: c:/windows/fonts/pala.ttf:1: unexpected symbol Jan ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___ -- - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] bug in beta: \tab results in text overlap
On 11/27/2013 5:08 PM, Lars Huttar wrote:
On 11/22/2013 4:34 PM, Hans Hagen wrote:
The problem, is/was that mixed columns had not yet mark
synchronization enabled. I uploaded a new beta. In the process I also
made marks a bit more restrictive but it might have (yet unknown) side
effects.
Hans, I tried the beta of 2013.11.26, and as mentioned in a previous
email, it fixes the \getmarking problem pretty well. However the same
beta has a fatal problem for us: lists using \tab are now broken.
MWE:
\starttext
\tab{AC}Autonomous Community\par
\tab{\it alt.}alternate name for\par
\stoptext
In the TeX Live 2013 version of mkiv, this gives us a nice table with
the headword separated from the definition.
In the beta, the headword and the definition start at the same
horizontal position, and overlap each other.
side effect of automatically cleaning up spaces (skips) ...
\setupdescription
[tab]
[sample=\kern4\emwidth] % was \hskip
fixed in next version
(this command is sort of obsolete)
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 2013-11-27 Hans Hagen wrote: On 11/27/2013 9:53 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 8:44 PM, Jan Tosovsky wrote: during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. the font pala.ttf has two entries i.sc and i see no reference to *.smcp There is no 'i.sc' glyph available according to the font software, only those .smcp, listed in the smcp6 table. As there are only .sc names in the TMA file, I suppose there is some kind of name normalization. But not very precise... mtxrun --script font --save pala.ttf I can confirm your observations. In this lua export there is no .smcp, but doubled i.sc records. Strange. There must be really some kind of normalization there... It would be nice to review the corresponding part of the code as it is IMHO potentially dangerous. I felt obliged to report it :-) Jan ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 11/27/2013 10:20 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 9:53 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 8:44 PM, Jan Tosovsky wrote: during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. the font pala.ttf has two entries i.sc and i see no reference to *.smcp There is no 'i.sc' glyph available according to the font software, only those .smcp, listed in the smcp6 table. As there are only .sc names in the TMA file, I suppose there is some kind of name normalization. But not very precise... mtxrun --script font --save pala.ttf I can confirm your observations. In this lua export there is no .smcp, but doubled i.sc records. Strange. There must be really some kind of normalization there... the fact that there are two i.sc in the font is suspicious ... best check the font in fontforge ... one never know what kind of things other programs do It would be nice to review the corresponding part of the code as it is IMHO potentially dangerous. afaik no magic there Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 2013-11-27 Hans Hagen wrote: On 11/27/2013 10:20 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 9:53 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 8:44 PM, Jan Tosovsky wrote: during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) The first one should have IMHO a different name, e.g. dotlessi.sc (to keep conventions). The same name for two glyphs might be dangerous. the fact that there are two i.sc in the font is suspicious ... best check the font in fontforge ... one never know what kind of things other programs do Hmm, FontForge glyphs naming corresponds to what we can observe in the ConTeXt (doubled i.sc). My previous analysis was based on FontLab. I am confused now... Jan ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Eliminating orpans in the Index
On 11/26/2013 10:09 PM, Jan Tosovsky wrote: On 2013-11-23 Jan Tosovsky wrote: in my two-column index there are several cases when the last entry in the given letter group overflows to the next column/page. In the extreme case it is just the last page reference. ... Additionaly, columns are not balanced properly in all cases. When the first is longer, it is not a big problem. But the opposite case looks weird. As the registers are rendered programatically, I cannot intervene into this process. But can I influence it e.g. using 'processors' applied to problematic index entries? Processors can be used for setting the font-weight or color of particular entry. Can the same method used for manual setting of 'keep-with-previous/next' ? I can think of a hack but it will always be for last minute work. Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [***SPAM***] Incorrect internal font processing
On 2013-11-27 Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 10:20 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 9:53 PM, Jan Tosovsky wrote: On 2013-11-27 Hans Hagen wrote: On 11/27/2013 8:44 PM, Jan Tosovsky wrote: during my attempts to patch the Palatino's dotless 'i' I found that this font is parsed incorrectly by ConTeXt. Comparing index/name info of individual glyphs in the font software and resulting pala.tma file there is the following difference: Index | Name - font| Name - tma 1110 | dotlessi.smcp | i.sc(1) 1170 | i.smcp | i.sc(2) The first one should have IMHO a different name. The same name for two glyphs might be dangerous. the fact that there are two i.sc in the font is suspicious ... best check the font in fontforge ... one never know what kind of things other programs do Hmm, FontForge glyphs naming corresponds to what we can observe in the ConTeXt (doubled i.sc). My previous analysis was based on FontLab. I am confused now... Actually, there are no names of these glyphs available in the font so they are calculated(!) Each of two programs uses a different method. FontLab method is based on layout tables - GPOS, GSUB, GDEF (it somehow detects that both glyps differs). The FontForge method is unclear and seems to be buggy. But we should blame rather the font itself as it is the primary cause of these problems (= missing glyph names). Jan ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
[NTG-context] Multi-letter variables in math mode
Hi. Sometimes I use variables (really rather abbreviations) in math formulas. It seems to me that the letterspacing is a bit too wide then. Maybe math mode thinks I want to multiply the letters as if they were variables for themselves. Is there a way to preserve normal letterspacing locally in a formula? Kind regards. ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] Multi-letter variables in math mode
On Wed, 27 Nov 2013, Thaddäus Töppen wrote:
Hi.
Sometimes I use variables (really rather abbreviations) in math formulas.
It seems to me that the letterspacing is a bit too wide then.
Maybe math mode thinks I want to multiply the letters as if they were variables
for themselves.
Is there a way to preserve normal letterspacing locally in a formula?
Latex provides a \mathit macro for such variables. From what I understand,
this is essentially the same as using \text{\it ...}. For example:
\starttext
\startformula \startalign
\NC efat \NR
\NC \text{\it efat} \NR
\stopalign \stopformula
\stoptext
You could wrap this around in a macro, if you wish (but don't use \mathit,
as that is reserved for normal math in context).
Aditya___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
