Re: [NTG-context] nomarking function in MKIV
Am 30.06.10 10:19, schrieb Alan BRASLAU:
On Tuesday 29 June 2010 19:33:55 Peter Münster wrote:
On Tue, Jun 29 2010, John Devereux wrote:
so that "Short Title Rest Of Title" appears as the chapter
title, but
just "Short Title" appears in the TOC, PDF bookmarks and footers.
\setupinteraction[state=start]
\placebookmarks[all]
\setupfootertexts[chapter]
\starttext
\completecontent
\startchapter[title=long, list=short, bookmark=bookmark, marking=footer]
bla
\stopchapter
\stoptext
Cheers, Peter
Three points:
[...]
(2)
Additionally,
\chapter [title={First chapter},list={First}]
does not work. Logically this should work just as \startchapter.
This won't happen but what you can do is to write a macro which accepts
different values for
headers/footers, the running text and the toc (i know the entries in the
toc and text are wrong).
\unprotect
\def\ca{ca}
\unexpanded\def\caption
{\dosingleargument\docaption}
\def\docaption[#1]%
{\getparameters[\ca][\c!title=,\c!list=\catitle,\c!marking=\catitle,#1]%
\doifmodeelse{*\v!marking}
{\camarking}
{\doifmodeelse{*\v!list}
{\calist}
{\catitle}}}
\protect
\setupheadertexts[chapter]
\starttext
\completecontent
\chapter{First Chapter}
\chapter{\caption[title=Second Chapter,list=Chapter Two,marking=Two]}
\stoptext
Wolfgang
___
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] \numstr errors out in chapter star logic
Am 28.06.10 23:33, schrieb Tom:
> The "lazy" method below yields eleven pages, each of which is headed by n
> Chapter n, where n represents the numerals from 1 to 11. The text version
of
> the chapter numbers do not appear.
>
>
\defineconversion[numstring][One,Two,Three,Four,Five,Six,Seven,Eight,Nine,Te
> n,Eleven]
>
> \setuphead[chapter]
> [conversion=numstring]
>
How should i know you're using mkii! Replace \setuphead with \setupsection:
\setupsection[chapter][conversion=numstring]
Wolfgang
The following example converts chapter numbers to words for the \chapter
logic but also converts chapter numbers to words in unwanted places such as
in the TOC and section numbers in the text.
\defineconversion[numstring][One,Two,Three,Four,Five,Six,Seven,Eight,Nine,Te
n,Eleven]
\setupsection[chapter]
[conversion=numstring]
\starttext
\completecontent
\dorecurse{11}{\chapter{Chapter #1}\par\section{Example section}}
\stoptext
Tom Benjey
717-258-9733 voice
717-243-0074 fax
Twitter: @TomBenjey
___
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] blurred shadow on images?
Am 30.06.10 14:39, schrieb Henning Hraban Ramm:
Am 2010-06-21 um 08:42 schrieb Taco Hoekwater:
Creating a semi-transparent backdrop with metapost is quite simple,
but I am not sure whether that works with cmyk, you'll have to try
yourself. Code goes something like this:
For the records: This is, how I'll use it:
\startuniqueMPgraphic{texthole}
for dx = 0 upto 40:
dy := dx;
wa := 10 + dx;
wb := \overlaywidth - dx - 10;
ha := dy + 10;
hb := \overlayheight - dy - 10;
fill (wa,ha)--(wb,ha)--(wb,hb)--(wa,hb)--cycle
withcolor transparent("normal", .04, black);
endfor;
\stopuniqueMPgraphic
\defineoverlay[shaded][\useMPgraphic{texthole}]
\starttext
\rotate[rotation=12]{%
\framed[height=50mm, width=50mm, frame=off, background=shaded,
backgroundoffset=5mm, align=middle]%
{\offset[x=1mm,y=-2mm]{\externalfigure[koe][width=50mm]}}%
}
\stoptext
I'm glad I found \offset, because framed's offset parameter can't
distinguish x and y offset.
Positive offset moves right and down, negative offset moves just up -
I guess that's a buglet.
You can change the boundingbox in the metapost graphic (the white
background was required
for the cow figure because it has a transparent background)
\startuniqueMPgraphic{shadow}
for dx = 0 upto 40:
dy := dx ;
wa := dx - 10 ;
wb := \overlaywidth - dx + 10 ;
ha := dy - 10 ;
hb := \overlayheight - dy + 10 ;
fill (wa,ha)--(wb,ha)--(wb,hb)--(wa,hb)--cycle
withcolor transparent("normal", .04, black);
endfor;
setbounds currentpicture to OverlayBox ;
\stopuniqueMPgraphic
\defineoverlay[shadow][\useMPgraphic{shadow}]
\starttext
\externalfigure[cow][width=50mm,background={shadow,color},backgroundcolor=white]
\stoptext
Wolfgang
___
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] CSS glitch in the garden
On Wed, Jun 30, 2010 at 17:00, Otared Kavian wrote: > Hello Hraban, Patrick, > > I just checked the website > http://wiki.contextgarden.net/Main_Page > with Safari 5.0 and Mac OS X 10.6.3 and everything seems allright, as it is > with FireFox. > Also using various different « User Agent » (in the « Develop » Menu) Safari > 5.0 works fine. > > Best regards: OK I get the same wrong (or at least weird) result in both Safari and Chrome, but that has been a problem for a very long time already, not only with Safari 5. Mojca <>___ 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 Linotype under MKIV
Thank you very much, Taco, especially for the detailed explanations you
gave! It works like a charm. I've made a new Wiki page (my first one),
mainly based on your answer:
http://wiki.contextgarden.net/Palatino_Linotype_under_MKIV
- Original Message -
From: "Taco Hoekwater"
To: "mailing list for ConTeXt users"
Cc: "Paul Schalck"
Sent: Wednesday, June 30, 2010 9:33 AM
Subject: Re: [NTG-context] Palatino Linotype under MKIV
Hi,
On 06/29/2010 11:15 AM, Paul Schalck wrote:
Hi,
I'm trying to use the full glyph range of the Palatino Linotype font
shipped with XP (version 1.40; significantly different from the Windows
7 one) under MKIV. Everything works fine (oldstyle figures, sups for
instance), except that the small cap "i" character has a dot whereas it
shouldn't.
I borrowed one of the fonts from my wife's XP install (pala.ttf).
The short answer: the font is borked, complain to Microsoft.
The long answer: lookups are name-based, and if there are two glyphs
with the same name, you can't know which one is used in any particular
piece of software.
As far as I can see, it has to do with the messy name list of the
glyphs. Both the normal small cap i and the small cap dotted i are named
"i.sc"
The one with a dot is meant for Turkish.
Moreover, the small cap glyphs have no unicode numbers in this font, so
I cannot pick them manually with \char" or even with \charX.
Any ideas how I can get the right dottless i?
Context always maps all unencoded glyphs into a private area starting
at 0xF. For this font, the first i.sc (the one without dot) is at
0xF00AF and has glyph index 0x456, and the second is at 0xF00EB
with glyph index 0x492.
To find these numbers, run a file like this:
\usemodule[fnt-10]
\starttext
\ShowCompleteFont{file:pala.ttf}{20pt}{1}
\stoptext
This means that to get the dotless version, you could enter \char"F00AF
Really long answer: to fix the problem nicely, we have to rename one of
the two glyphs.
This could be done in an external editor, but as this is a system font,
that may not be wise or even possible. Luckily, context allows to do
this using a patching system that is active during initial font loading
time (when the cache is generated).
In the following, we will be patching the generated cache file before
it is saved (by putting some lua code at the beginning of your test
file). Remember that you have to delete the generated cache
files after each iteration. In my case, they were /opt/tex/texmf-
cache/luatex-cache/context/c24894930eb65eadf7b71f1e305ff518/fonts/otf/pala.tm*.
If you forget to do this step in between runs,
nothing will change in the output!
The existing font patches are in font-pat.lua, and from that file it is
possible to deduce that something like this is the correct program
structure, theoretically:
\startluacode
function palapatch (data,filename)
-- to be filled in
end
fonts.otf.enhancers.patches["^pala"] = palapatch
\stopluacode
The two arguments to the patch function are the data table from the
luafontloader and the font file name, respectively. The function
should patch the data table to our liking and does not have to return
anything.
In order to have a good look at the data, the first thing to do is to
dump the data to a file. Put this code at the top of your test file,
delete the data cache files, and run:
\startluacode
function palapatch (data,filename)
io.savedata(filename .. '.lua', table.serialize(data))
end
fonts.otf.enhancers.patches["^pala"] = palapatch
\stopluacode
\definefontfeature [...]
Afterwards, open pala.ttf.lua (or pala.TTF.lua. not sure how this works
out on an actual XP install) in an editor for browsing.
Looking at the lua code in pala.ttf.lua, you will see that there
is a pretty large sub-array called 'glyphs', which happens to be
indexed by glyph id. There are two entries in that sub-array called
'i.sc' and we will want to change the second of those to 'i.scturkish'
(the one at 0x492, the number we discovered above).
Change the lua code to the code below, save your test file, delete the
data cache again, and rerun.
\startluacode
function palapatch (data,filename)
data.glyphs[0x492].name = "a.scturkish"
end
fonts.otf.enhancers.patches["^pala"] = palapatch
\stopluacode
That's one problem fixed. If you look at the test's pdf, it will now
have dotless i's in the smallcaps. But now we have broken the
turkish smallcaps code (it will now also use the first i.sc, which is
wrong) so it is nice to fix that as well. Some searching back and forth
through the pala.ttf.lua code reveals that there are two lookups that
use i.sc: ss_latn_l_13_s (for normal latin) and ss_latn_l_14_s (for
turkish). These lookups are part of the glyph definition of 'i' which
lives at 0x92 (I found that number in the earlier font dump, but you
could also count the entries in pala.ttf.lua, if you are bored or like
counting stuff).
Named lookups are small arrays (you can deduce that from th
Re: [NTG-context] CSS glitch in the garden
Hello Hraban, Patrick, I just checked the website http://wiki.contextgarden.net/Main_Page with Safari 5.0 and Mac OS X 10.6.3 and everything seems allright, as it is with FireFox. Also using various different « User Agent » (in the « Develop » Menu) Safari 5.0 works fine. Best regards: OK On 30 juin 2010, at 16:10, Patrick Gundlach wrote: > Hello Hraban, > >> the menu column appears below instead left of the content area. >> logo position is ok, x positions of the areas seem also ok, just the y >> position of the menu area is wrong. > > I get the same results in Firefox and in Safari 5. So I cannot see the > problem. Perhaps you can send me some screenshots (off list)? > > Patrick > > ___ > 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 > ___ ___ 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] mtxrun error
On Wed, Jun 30, 2010 at 9:36 AM, Alan BRASLAU wrote: > Latest minimals: > > mtxrun:9289: attempt to concatenate local 'v' (a table value) confirmed on my linux 32 box too -- luigi ___ 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] CSS glitch in the garden
Hello Hraban, > the menu column appears below instead left of the content area. > logo position is ok, x positions of the areas seem also ok, just the y > position of the menu area is wrong. I get the same results in Firefox and in Safari 5. So I cannot see the problem. Perhaps you can send me some screenshots (off list)? Patrick ___ 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] CSS glitch in the garden
I guess Safari 5 changed some CSS behaviour, because in Firefox it's still ok: the menu column appears below instead left of the content area. logo position is ok, x positions of the areas seem also ok, just the y position of the menu area is wrong. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer) ___ 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] blurred shadow on images?
Am 2010-06-21 um 08:42 schrieb Taco Hoekwater:
Creating a semi-transparent backdrop with metapost is quite simple,
but I am not sure whether that works with cmyk, you'll have to try
yourself. Code goes something like this:
For the records: This is, how I'll use it:
\startuniqueMPgraphic{texthole}
for dx = 0 upto 40:
dy := dx;
wa := 10 + dx;
wb := \overlaywidth - dx - 10;
ha := dy + 10;
hb := \overlayheight - dy - 10;
fill (wa,ha)--(wb,ha)--(wb,hb)--(wa,hb)--cycle
withcolor transparent("normal", .04, black);
endfor;
\stopuniqueMPgraphic
\defineoverlay[shaded][\useMPgraphic{texthole}]
\starttext
\rotate[rotation=12]{%
\framed[height=50mm, width=50mm, frame=off, background=shaded,
backgroundoffset=5mm, align=middle]%
{\offset[x=1mm,y=-2mm]{\externalfigure[koe][width=50mm]}}%
}
\stoptext
I'm glad I found \offset, because framed's offset parameter can't
distinguish x and y offset.
Positive offset moves right and down, negative offset moves just up -
I guess that's a buglet.
Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net/texnique/
http://wiki.contextgarden.net
https://www.cacert.org (I'm an assurer)
___
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] nomarking function in MKIV (selector)
On nomarking functionality in MKIV:
I manage short/long figure captions using a selector:
\defineselector [caption] [max=2,n=2] % alternate {short}{long} captions
...
\placefigure [here] [fig:reference]
{\select{caption}
{short}
{long}
}
{figure}
...
\chapter{Liste des figures}
\start
\setupselector [caption] [n=1]
\placelistoffigures [criterium=all]
\stop
Similarly to
\startchapter [title=long,list=short]
could we have:
\placefigure [here] [fig:reference] [caption={long},list={short}]
{figure}
Could this coexist with the current syntax:
\placefigure [here] [fig:reference]
{caption}
{figure}
Alan
By the way, \select{caption} does not follow the general syntax rule
whereas metadata is contained between []
and text to be typeset between {}
One should thus rather have
\select [caption] {short} {long}
or even
\selectcaption {short} {long}
to be coherent.
___
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] nomarking function in MKIV
On Wed, Jun 30 2010, Alan BRASLAU wrote:
> I would then expect to be able to use:
> \setupchapter [bookmark=list]
> to select to put the short title (if list={short}) in the bookmarks,
> unless there be bookmark={shorter}.
Good idea, +1 !
Peter
--
Contact information: http://pmrb.free.fr/contact/
___
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] nomarking function in MKIV
On Tuesday 29 June 2010 19:33:55 Peter Münster wrote:
> On Tue, Jun 29 2010, John Devereux wrote:
> > so that "Short Title Rest Of Title" appears as the chapter title, but
> > just "Short Title" appears in the TOC, PDF bookmarks and footers.
>
> \setupinteraction[state=start]
> \placebookmarks[all]
> \setupfootertexts[chapter]
> \starttext
> \completecontent
> \startchapter[title=long, list=short, bookmark=bookmark, marking=footer]
> bla
> \stopchapter
> \stoptext
>
> Cheers, Peter
Three points:
(1)
\setupinteraction [state=start,option=bookmark,contrastcolor=interactioncolor]
\setupinteractionscreen [option=bookmark]
\placebookmarks [part,chapter,section,subsection]
[part,chapter,section]
\starttext
\completecontent
\startchapter [title={First chapter},list={First}]
text̛̛
\stopchapter
\stoptext
Here, the long title gets placed by default in the bookmarks,
whereas one probably wants the short title there. Of course,
one can use "bookmark={First}", but this might be redundant
and thus is not very elegant. An alternative might be to
use "bookmark=list" but this, of course, yields "list".
Could/should one require the syntax: title={long},list={short}?
I would then expect to be able to use:
\setupchapter [bookmark=list]
to select to put the short title (if list={short}) in the bookmarks,
unless there be bookmark={shorter}.
(2)
Additionally,
\chapter [title={First chapter},list={First}]
does not work. Logically this should work just as \startchapter.
(3)
Furthermore, I have a conceptual/structural problem with
\startchapter\stopchapter. Take the example:
\startchapter [title={First chapter}]
bla
\stopchapter
some text
\startchapter [title={Second chapter}]
bla
\stopchapter
Where does "some text" belong? Structurally, I mean.
Is it some sort of interlude?
The syntax \chapter is not only convenient,
it is also logical in that the structural section
remains valid until the following \chapter.
The \startchapter\stopchapter syntax is attractive
but leaves me a bit perplex. Would someone explain?
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] [metapost] mptopdf from the command line in ConTeXt minimals?...
On Wed, Jun 30, 2010 at 2:45 AM, Stuart Hungerford wrote: > Hi, > > I'm a ConTeXt and Metapost newbie, so apologies in advance if > this is a stupid question. > > I've successfully installed ConTeXt minimals on an OS/X 10.6.x > system and it seems to be running okay. I'd like to run some > metapost examples from the command line and "mpost" also seems > to be running well. > > I've seen references to a "mptopdf" script and there is a Perl > script of that name but it looks like it needs to be installed > somewhere. Is there some post-setup procedure I need to follow > to access "mptopdf" or another one I've seen references to > "fmtutil"? > > Thanks, > > Stu context mkiv of minimals uses mplib which is integrated in luatex, so it's the fastest way to produce a pdf : for example %%save as %%test-0001.tex \starttext \startMPpage path p; p := fullcircle scaled 1 cm; draw p scaled 4 withpen pencircle xscaled 2mm yscaled 4mm rotated 30 ; \stopMPpage \stoptext $>context test-0001.tex With context mkii (again of minimals) is almost the same $>mtxrun texexec test-0001.tex but metapost is called with a system command , so it's more slow. (google metafun-s.pdf for more info about metafun) -- luigi ___ 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] [metapost] mptopdf from the command line in ConTeXt minimals?...
On Wed, Jun 30, 2010 at 02:45, Stuart Hungerford wrote: > > I've seen references to a "mptopdf" script and there is a Perl > script of that name but it looks like it needs to be installed > somewhere. Is there some post-setup procedure I need to follow > to access "mptopdf" or another one I've seen references to > "fmtutil"? The minimals use a lua version of that script. It should run automatically, or at least "semi-automatically" after you run luatools --generate. After that just execute mptopdf myfile.mp Mojca ___ 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 Linotype under MKIV
On Wed, Jun 30, 2010 at 9:33 AM, Taco Hoekwater wrote:
>
> Hi,
>
> On 06/29/2010 11:15 AM, Paul Schalck wrote:
>>
>> Hi,
>>
>> I'm trying to use the full glyph range of the Palatino Linotype font
>> shipped with XP (version 1.40; significantly different from the Windows
>> 7 one) under MKIV. Everything works fine (oldstyle figures, sups for
>> instance), except that the small cap "i" character has a dot whereas it
>> shouldn't.
>
> I borrowed one of the fonts from my wife's XP install (pala.ttf).
>
> The short answer: the font is borked, complain to Microsoft.
>
> The long answer: lookups are name-based, and if there are two glyphs
> with the same name, you can't know which one is used in any particular
> piece of software.
>
>> As far as I can see, it has to do with the messy name list of the
>> glyphs. Both the normal small cap i and the small cap dotted i are named
>> "i.sc"
>
> The one with a dot is meant for Turkish.
>
>> Moreover, the small cap glyphs have no unicode numbers in this font, so
>> I cannot pick them manually with \char" or even with \charX.
>>
>> Any ideas how I can get the right dottless i?
>
> Context always maps all unencoded glyphs into a private area starting
> at 0xF. For this font, the first i.sc (the one without dot) is at
> 0xF00AF and has glyph index 0x456, and the second is at 0xF00EB
> with glyph index 0x492.
>
> To find these numbers, run a file like this:
>
> \usemodule[fnt-10]
> \starttext
> \ShowCompleteFont{file:pala.ttf}{20pt}{1}
> \stoptext
>
> This means that to get the dotless version, you could enter \char"F00AF
>
> Really long answer: to fix the problem nicely, we have to rename one of
> the two glyphs.
>
> This could be done in an external editor, but as this is a system font,
> that may not be wise or even possible. Luckily, context allows to do
> this using a patching system that is active during initial font loading
> time (when the cache is generated).
>
> In the following, we will be patching the generated cache file before
> it is saved (by putting some lua code at the beginning of your test
> file). Remember that you have to delete the generated cache
> files after each iteration. In my case, they were /opt/tex/texmf-
> cache/luatex-cache/context/c24894930eb65eadf7b71f1e305ff518/fonts/otf/pala.tm*.
> If you forget to do this step in between runs,
> nothing will change in the output!
>
> The existing font patches are in font-pat.lua, and from that file it is
> possible to deduce that something like this is the correct program
> structure, theoretically:
>
> \startluacode
> function palapatch (data,filename)
> -- to be filled in
> end
> fonts.otf.enhancers.patches["^pala"] = palapatch
> \stopluacode
>
> The two arguments to the patch function are the data table from the
> luafontloader and the font file name, respectively. The function
> should patch the data table to our liking and does not have to return
> anything.
>
> In order to have a good look at the data, the first thing to do is to
> dump the data to a file. Put this code at the top of your test file,
> delete the data cache files, and run:
>
> \startluacode
> function palapatch (data,filename)
> io.savedata(filename .. '.lua', table.serialize(data))
> end
>
> fonts.otf.enhancers.patches["^pala"] = palapatch
> \stopluacode
>
> \definefontfeature [...]
>
> Afterwards, open pala.ttf.lua (or pala.TTF.lua. not sure how this works
> out on an actual XP install) in an editor for browsing.
>
> Looking at the lua code in pala.ttf.lua, you will see that there
> is a pretty large sub-array called 'glyphs', which happens to be
> indexed by glyph id. There are two entries in that sub-array called
> 'i.sc' and we will want to change the second of those to 'i.scturkish'
> (the one at 0x492, the number we discovered above).
>
> Change the lua code to the code below, save your test file, delete the
> data cache again, and rerun.
>
> \startluacode
> function palapatch (data,filename)
> data.glyphs[0x492].name = "a.scturkish"
> end
>
> fonts.otf.enhancers.patches["^pala"] = palapatch
> \stopluacode
>
> That's one problem fixed. If you look at the test's pdf, it will now
> have dotless i's in the smallcaps. But now we have broken the
> turkish smallcaps code (it will now also use the first i.sc, which is
> wrong) so it is nice to fix that as well. Some searching back and forth
> through the pala.ttf.lua code reveals that there are two lookups that
> use i.sc: ss_latn_l_13_s (for normal latin) and ss_latn_l_14_s (for
> turkish). These lookups are part of the glyph definition of 'i' which
> lives at 0x92 (I found that number in the earlier font dump, but you
> could also count the entries in pala.ttf.lua, if you are bored or like
> counting stuff).
>
> Named lookups are small arrays (you can deduce that from the double
> braces in pala.ttf.lua), so the needed patch is:
>
>
> data.glyphs[0x92].lookups["ss_latn_l_14_s"][1].specification.variant="a.scturkish"
>
> And that will fix the turk
[NTG-context] mtxrun error
Latest minimals: mtxrun:9289: attempt to concatenate local 'v' (a table value) 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 Linotype under MKIV
Hi,
On 06/29/2010 11:15 AM, Paul Schalck wrote:
Hi,
I'm trying to use the full glyph range of the Palatino Linotype font
shipped with XP (version 1.40; significantly different from the Windows
7 one) under MKIV. Everything works fine (oldstyle figures, sups for
instance), except that the small cap "i" character has a dot whereas it
shouldn't.
I borrowed one of the fonts from my wife's XP install (pala.ttf).
The short answer: the font is borked, complain to Microsoft.
The long answer: lookups are name-based, and if there are two glyphs
with the same name, you can't know which one is used in any particular
piece of software.
As far as I can see, it has to do with the messy name list of the
glyphs. Both the normal small cap i and the small cap dotted i are named
"i.sc"
The one with a dot is meant for Turkish.
Moreover, the small cap glyphs have no unicode numbers in this font, so
I cannot pick them manually with \char" or even with \charX.
Any ideas how I can get the right dottless i?
Context always maps all unencoded glyphs into a private area starting
at 0xF. For this font, the first i.sc (the one without dot) is at
0xF00AF and has glyph index 0x456, and the second is at 0xF00EB
with glyph index 0x492.
To find these numbers, run a file like this:
\usemodule[fnt-10]
\starttext
\ShowCompleteFont{file:pala.ttf}{20pt}{1}
\stoptext
This means that to get the dotless version, you could enter \char"F00AF
Really long answer: to fix the problem nicely, we have to rename one of
the two glyphs.
This could be done in an external editor, but as this is a system font,
that may not be wise or even possible. Luckily, context allows to do
this using a patching system that is active during initial font loading
time (when the cache is generated).
In the following, we will be patching the generated cache file before
it is saved (by putting some lua code at the beginning of your test
file). Remember that you have to delete the generated cache
files after each iteration. In my case, they were /opt/tex/texmf-
cache/luatex-cache/context/c24894930eb65eadf7b71f1e305ff518/fonts/otf/pala.tm*.
If you forget to do this step in between runs,
nothing will change in the output!
The existing font patches are in font-pat.lua, and from that file it is
possible to deduce that something like this is the correct program
structure, theoretically:
\startluacode
function palapatch (data,filename)
-- to be filled in
end
fonts.otf.enhancers.patches["^pala"] = palapatch
\stopluacode
The two arguments to the patch function are the data table from the
luafontloader and the font file name, respectively. The function
should patch the data table to our liking and does not have to return
anything.
In order to have a good look at the data, the first thing to do is to
dump the data to a file. Put this code at the top of your test file,
delete the data cache files, and run:
\startluacode
function palapatch (data,filename)
io.savedata(filename .. '.lua', table.serialize(data))
end
fonts.otf.enhancers.patches["^pala"] = palapatch
\stopluacode
\definefontfeature [...]
Afterwards, open pala.ttf.lua (or pala.TTF.lua. not sure how this works
out on an actual XP install) in an editor for browsing.
Looking at the lua code in pala.ttf.lua, you will see that there
is a pretty large sub-array called 'glyphs', which happens to be
indexed by glyph id. There are two entries in that sub-array called
'i.sc' and we will want to change the second of those to 'i.scturkish'
(the one at 0x492, the number we discovered above).
Change the lua code to the code below, save your test file, delete the
data cache again, and rerun.
\startluacode
function palapatch (data,filename)
data.glyphs[0x492].name = "a.scturkish"
end
fonts.otf.enhancers.patches["^pala"] = palapatch
\stopluacode
That's one problem fixed. If you look at the test's pdf, it will now
have dotless i's in the smallcaps. But now we have broken the
turkish smallcaps code (it will now also use the first i.sc, which is
wrong) so it is nice to fix that as well. Some searching back and forth
through the pala.ttf.lua code reveals that there are two lookups that
use i.sc: ss_latn_l_13_s (for normal latin) and ss_latn_l_14_s (for
turkish). These lookups are part of the glyph definition of 'i' which
lives at 0x92 (I found that number in the earlier font dump, but you
could also count the entries in pala.ttf.lua, if you are bored or like
counting stuff).
Named lookups are small arrays (you can deduce that from the double
braces in pala.ttf.lua), so the needed patch is:
data.glyphs[0x92].lookups["ss_latn_l_14_s"][1].specification.variant="a.scturkish"
And that will fix the turkish lookup. Now, I want to make sure we
only run this code for palatino version 1.40 (it should be obvious
why), and it is nice to do a terminal message as well. (note: testing
for just the font version ignores the fact that different vendors may
use the same font name for d
[NTG-context] [metapost] mptopdf from the command line in ConTeXt minimals?...
Hi, I'm a ConTeXt and Metapost newbie, so apologies in advance if this is a stupid question. I've successfully installed ConTeXt minimals on an OS/X 10.6.x system and it seems to be running okay. I'd like to run some metapost examples from the command line and "mpost" also seems to be running well. I've seen references to a "mptopdf" script and there is a Perl script of that name but it looks like it needs to be installed somewhere. Is there some post-setup procedure I need to follow to access "mptopdf" or another one I've seen references to "fmtutil"? Thanks, Stu -- Stuart Hungerford ANU Supercomputer Facility ___ 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 ___
