Re: [NTG-context] Placefigure without Caption-Numbering
On Sat, 30 Nov 2013 21:06:20 +0100 Jan Tosovsky wrote: > Indeed much cleaner. But that numbering option seems to be ignored ;-) > Does it work for you? Sorry, it is "number=no". Alan ___ 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-17 Jan Tosovsky wrote:
>
> 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.
>
almost fixed now using this procedure:
1) Create a new LFG file
local fix_pala = {
comment = "Switching i.sc glyphs indexes",
fixes = function(data)
local descriptions = data.descriptions
descriptions[983201].index = 1170
descriptions[983261].index = 1110
end
}
return {
name = "pala",
comment = "Switching the small capped 'i' to a dotless variant in
Palatino Linotype.",
treatments = {
["pala.ttf"] = fix_pala,
["palai.ttf"] = fix_pala,
["palab.ttf"] = fix_pala,
["palabi.ttf"] = fix_pala,
},
}
2) Place it into the folder where other LFG files are stored
(tex\texmf-context\tex\context\fonts)
3) Execute 'mtxrun --generate' command to include newly added LFG file
into a file database
4) Specify a new font feature referencing to this goodie in the source file:
\definefontfeature[dotlessi][mode=base,goodies=pala]
\definefontfamily[palatino][rm][Palatino
Linotype][features={default,quality,dotlessi}]
\setupbodyfont[palatino]
\starttext
{Athenians \smallcaps{Athenians}}\par
{Athenians \sc{Athenians}}\par
{\it Athenians \smallcaps{Athenians}}\par
{\bf Athenians \smallcaps{Athenians}}\par
{\bi Athenians \smallcaps{Athenians}}\par
\stoptext
5) Trigger the generating
It works except the regular font style. In this case \smallcaps option
behaves differently than for e.g. \it or \bf styles. I am quite confused.
Moreover, when faked caps are switched on using \sc, it works. Can anybody
explain what is happening here?
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 Wed, Nov 27, 2013 at 11:35:01PM +0100, Jan Tosovsky wrote: > 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(!) Right, the font (like many MS fonts) uses version 3 ‘post’ table which includes no glyph names at all, software that needs glyph names (e.g. LuaTeX, since you can’t embed a font is PDF without glyph names else printers would go nuts) have to generate it. Some software will use dump names; glyph1 etc. using glyph id, others will try to guess more sensible names from the OpenType layout tables. > 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. FontForge uses the layout tables, too, but this font has a catch, it has two → substitutions in the ‘smcp’ feature, one to a dotted small cap for Turkish (under TRK tag) and a regular one, and FontForge just names the resultant glyph ‘i.sc’ in both cases since it does not seem to check for duplicates, thinking that only one such a substitution can happen per feature. LuaTeX uses a (subset of) FontForge internally, so you get the same bug. It is not clear to me how FontLab arrived to the dotlessi name from the GSUB table, but I need to look into the font a bit more closer. Regards, Khaled ___ 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 Sun, Dec 01, 2013 at 11:21:30AM +0200, Khaled Hosny wrote: > It is not clear to me how FontLab arrived to the dotlessi name from the > GSUB table, but I need to look into the font a bit more closer. Interestingly, after I patched Sorts Mill (a FontForge fork) to avoid duplicates[1] I ended up with a ‘dotlessi.sc’ glyph, as it turns out the font has a → later on, so that is where FontLab gets the glyph name, too. I’ll try to port this patch to LuaTeX later. Regards, Khaled [1] https://bitbucket.org/sortsmill/sortsmill-tools/commits/a7fdc1cd13d94659fe90848d0fe2878bbdd54d60 ___ 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***] RE: Footnote line position
On 2013-11-22 Jan Tosovsky wrote:
>
> when a single line footnote is used, the footnote divider is
> rendered in larger distance than for footnotes with two or
> more lines (I mean a gap between the line and the footnote text).
>
> It can be tested easily:
>
> \chapter{Chapter}Foo\footnote{Bar}.
> \chapter{Chapter}Foo\footnote{Bar
>
> Bar}.
>
This behaviour seems to be driven by this code in strc-not.mkvi:
\unexpanded\def\normalnoterule
{\ifvmode
\dontleavehmode \blackrule
[\c!color=\noteparameter\c!rulecolor,
\c!width=.2\hsize,
\c!height=\noteparameter\c!rulethickness,
\c!depth=\zeropoint]%
\endgraf
\kern\strutdepth
\fi}
When e.g. \endgraf or \kern\strutdepth lines are commented, the gap is
smaller, but still different.
Changing the depth from \zeropoint to a bigger value (1cm) makes the gap
same, but it leads to extreme thick rule.
What else could be tweaked here?
Thnaks, 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] vertical square root upstroke (instead of having a slant)
With the following minimal file on MkIV (2013.05.28 00:36 MKIV current),
the upstroke of the square root is vertical instead of having the usual
slant toward the right. With MkII it has the usual slant.
I see this problem only with certain arrangements of variables (that
recur often in my book chapter on springs and piano strings). For
example, it goes away after changing the "\rho" to a "b".
\starttext
\startformula
\sqrt{Tb^2\over \rho}.
\stopformula
\stoptext
I know that the big math symbols are constructed differently in MkIV
and MkII. Does the example above show an intended difference?
--
-Sanjoy
___
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] Keeping titles together with the following text when grid is on
Hello,
this is not the same question as handling orphan and widows - because
you surely do not want some titles with only 2-3 lines of body text
after them.
I always use "\testpage[x]" to handle those issues, see your example
with testpage:
\setuppapersize[B5]
\startsetups[grid][mypenalties]
\setdefaultpenalties
\setpenalties\widowpenalties{2}{1}
\setpenalties\clubpenalties {2}{1}
\stopsetups
\setuphead[section]
[before={\testpage[8]\blank}]
%comment the following line to see the difference
\setuplayout[grid=yes, setups=mypenalties]
\showgrid
\starttext
\blank[force, 9.5cm]
\input tufte
\section{Tufte}
\input tufte
\stoptext
Huseyin
___
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
___
