On Sat, 20 Dec 2014 23:26:29 +0100, Pablo Rodriguez wrote:

On 12/20/2014 07:31 PM, j. van den hoff wrote:

...

newbie question:

how can I get access to fonts installed outside the TeX tree under MacOSX (10.9 to be precise)?

mtxrun --script font --list --name --pattern=*

shows lots of fonts (so they are recognized by context, I'd guess)

but the simple-minded approach, namely to trying something like

\starttypescript [stix] \definetypeface [stix] [rm] [serif] [stix] [default] \definetypeface [stix] [ss] [sans] [adventor] [default] \definetypeface [stix] [tt] [mono] [cursor] [default] \definetypeface [stix] [mm] [math] [stix] [default] \stoptypescript

\usetypescript[stix] \setupbodyfont[stix,12pt]

fails with `unknown library stix'.

obviously I am doing something wrong -- or is this a luatex problem not being able to find the system fonts?

Hi Jörg,

hi pablo,

I don’t have a Mac, but this works in ConTeXt:

\definefontfamily [mainface] [serif] [TeX Gyre Pagella] \definefontfamily [mainface] [sans] [Helvetica] \definefontfamily [mainface] [mono] [Courier] \definefontfamily [mainface] [math] [TeX Gyre Pagella Math] \setupbodyfont[mainface]

yes this seems to work (mostly, at least -- there are still some hickups). thanks a lot for this solution.

You don’t need to define a typescript. \definefontfamily is the command you need.

Typeface should be defined only once ([rm] and [serif] are redundant).

essentially, I copied/pasted this from contextgarden and my understanding was that `rm' and `serif' are aliases? also: why does the typescript definition does not work in the first place?

Default body font size is 12pt.

I think it is easier to invoke typefaces with the system font name. I mean, use the same name as you use in Word or any other MacOS X program.

understood. OTOH, ` mtxrun --script font --list --name --pattern=*' lists the fonts using a different convention (lower case, no blanks), so I am undecided what might be the "best practice" here?

I hope this helps. Don’t hesitate to ask, if you have further questions.

well, see above ;-). joerg

Pablo

-- Using Opera's revolutionary email client: http://www.opera.com/mail/

On Sat, 20 Dec 2014 23:26:29 +0100, Pablo Rodriguez wrote:

Hi Jörg, I don’t have a Mac, but this works in ConTeXt: \definefontfamily [mainface] [serif] [TeX Gyre Pagella] \definefontfamily [mainface] [sans] [Helvetica] \definefontfamily [mainface] [mono] [Courier] \definefontfamily [mainface] [math] [TeX Gyre Pagella Math] \setupbodyfont[mainface]

I've now looked a bit closer: this works (on my Mac) _except_ for the teletype font: `\tt{some text}' ends up being typeset in the serif font. `Courier' is there, for sure (meaning: it is listed by `mtxrun --script font...' but it does not work. on closer inspection, the actually found fontfiles are `courier new.ttf' and specifying [couriernew] _does_ work. so it seems you are right regarding using the "full" names, e.g. \definefontfamily [mainface] [sans] [adventor] does not work while \definefontfamily [mainface] [sans] [TeX Gyre Adventor] does. any ideas, why all this is happening? or: _how_ exactly can fonts be specified? how is the mapping from symbolic names to actual font files performed. it seems, sometimes symbolic (short) names work, sometimes they don't. so, is there some prescription, what is the right (TM) way to do it? -- Using Opera's revolutionary email client: http://www.opera.com/mail/

On Sun, 21 Dec 2014 17:20:33 +0100, Pablo Rodriguez wrote:

On 12/21/2014 02:31 PM, j. van den hoff wrote:

...

On Sat, 20 Dec 2014 23:26:29 +0100, Pablo Rodriguez wrote:

...

Hi Jörg, I don’t have a Mac, but this works in ConTeXt: \definefontfamily [mainface] [serif] [TeX Gyre Pagella] \definefontfamily [mainface] [sans] [Helvetica] \definefontfamily [mainface] [mono] [Courier] \definefontfamily [mainface] [math] [TeX Gyre Pagella Math] \setupbodyfont[mainface]

I've now looked a bit closer: this works (on my Mac) _except_ for the teletype font: `\tt{some text}' ends up being typeset in the serif font. `Courier' is there, for sure (meaning: it is listed by `mtxrun --script font...' but it does not work. on closer inspection, the actually found fontfiles are `courier new.ttf' and specifying [couriernew] _does_ work.

Hi Jörg,

\tt is a switch, so the right way to deploy it is:

{\tt this text should be typewritten text}

yes, that's right.

I have just discovered that Courier doesn’t work on my system either. I cannot find it.

Could you give the output from the following command?

$ mtxrun --script font --list --name --pattern=courier*

sure: courier courier pcrr8a.afm courierbold courierbold pcrb8a.afm courierboldoblique courierboldoblique pcrbo8a.afm couriermedium courier pcrr8a.afm couriernew couriernewpsmt /Library/Fonts/Courier New.ttf couriernewbold couriernewpsboldmt /Library/Fonts/Courier New Bold.ttf couriernewbolditalic couriernewpsbolditalicmt /Library/Fonts/Courier New Bold Italic.ttf couriernewitalic couriernewpsitalicmt /Library/Fonts/Courier New Italic.ttf couriernewnormal couriernewpsitalicmt /Library/Fonts/Courier New Italic.ttf couriernewpsbolditalicmt couriernewpsbolditalicmt /Library/Fonts/Courier New Bold Italic.ttf couriernewpsboldmt couriernewpsboldmt /Library/Fonts/Courier New Bold.ttf couriernewpsitalicmt couriernewpsitalicmt /Library/Fonts/Courier New Italic.ttf couriernewpsmt couriernewpsmt /Library/Fonts/Courier New.ttf couriernewregular couriernewpsmt /Library/Fonts/Courier New.ttf courieroblique courieroblique pcrro8a.afm as I wrote in the last mail, only the `courier new' fonts are represented by actual font-files it seems (don't know what the *afm files are). so if only those (and their abbreviations) were reported I would not have any problem. but as it stands, `courier' is reported as well -- but does not map to any actual font-file.

...

so it seems you are right regarding using the "full" names, e.g.

\definefontfamily [mainface] [sans] [adventor]

does not work while

\definefontfamily [mainface] [sans] [TeX Gyre Adventor]

does.

any ideas, why all this is happening?

\definefontfamily [mainface] [sans] [texgyreadventor]

seems to be the right way to invoke the font.

...

or: _how_ exactly can fonts be specified? how is the mapping from symbolic names to actual font files performed. it seems, sometimes symbolic (short) names work, sometimes they don't. so, is there some prescription, what is the right (TM) way to do it?>

I think using full names is a good way to do it. But TeX Gyre Adventor comes with ConTeXt. You don’t have it installed on your system.

yes, that I know. they are part of the texlive distribution I use. thanks for your help, joerg

Pablo

-- kUsing Opera's revolutionary email client: http://www.opera.com/mail/

On Sun, 21 Dec 2014 19:22:22 +0100, Pablo Rodriguez wrote:

On 12/21/2014 06:37 PM, j. van den hoff wrote:

...

On Sun, 21 Dec 2014 17:20:33 +0100, Pablo Rodriguez wrote:

...

On 12/21/2014 02:31 PM, j. van den hoff wrote: [...] as I wrote in the last mail, only the `courier new' fonts are represented by actual font-files it seems (don't know what the *afm files are). so if only those (and their abbreviations) were reported I would not have any problem. but as it stands, `courier' is reported as well -- but does not map to any actual font-file.

.afm is an Adobe font metrics file. This is the way (old) PostScript fonts are designed. Font glyphs in PostScript fonts are cotained in .pfa or .pfb files.

I see.

Wikipedia has a good article explaining PostScript fonts (https://en.wikipedia.org/wiki/PostScript_fonts). But unless you have an special interest, I’d simply ignore it.

If I‘m not wrong, only system font files are listed with their path. The fonts that come with ConTeXt are listed, but their paths are ignored.

BTW, this should work (if I’m not completely wrong [it doesn’t work on my system, because the courier fonts aren’t listed]):

\definefontfamily [mainface] [tt] [courier]

no, that does not work (despite it being listed by `mtxrun...fonts'. I need to specify 'courier new' here.

...

...

...

so it seems you are right regarding using the "full" names, e.g.

\definefontfamily [mainface] [sans] [adventor]

does not work while

\definefontfamily [mainface] [sans] [TeX Gyre Adventor]

does.

any ideas, why all this is happening?

\definefontfamily [mainface] [sans] [texgyreadventor]

seems to be the right way to invoke the font.

Sorry, I’m afraid my explanation was incomplete.

adventor is the name of a(n already predefined) typescript. So you can use it with \setupbodyfont and \switchtobodyfont.

texgyreadventor is the name of the typeface or font family. You should use it with \definefontfamily.

But typefaces cannot be invoked with typescript names and typescripts cannot be invoked with typeface names.

This is why \definefontfamily[mainface][sans][adventor] or \setupbodyfont[texgyreadventor] don’t work.

Wolfgang will know that better, but [mainface] in the previous \definefontfamily is the new and easy way to create typescripts in ConTeXt.

Using the full font name has the main advantage of not having to know whether a given name designs a typescript or a typeface ;-).

I hope it will be clearer now. Let me know if it isn’t.

yes it is (to an extent ;-)). I'll keep this labeled for lookup... but I'm already stumbling about the next thing. while playing around with some nice fonts I also tried out `optima' (like palatino by h. zapf). so that is what I see: mtxrun --script font --list --all --name --pattern=*optima* optima optimaextrablack /System/Library/Fonts/Optima.ttc index: 0 optimablack optimaextrablack /System/Library/Fonts/Optima.ttc index: 0 optimabold optimabold /System/Library/Fonts/Optima.ttc index: 3 optimabolditalic optimabolditalic /System/Library/Fonts/Optima.ttc index: 1 optimaextrablack optimaextrablack /System/Library/Fonts/Optima.ttc index: 0 optimaitalic optimaitalic /System/Library/Fonts/Optima.ttc index: 2 optimanormal optimaitalic /System/Library/Fonts/Optima.ttc index: 2 optimaregular optimaregular /System/Library/Fonts/Optima.ttc index: 4 then, when using, e.g., \definefontfamily [mainface] [serif] [Optima] \definefontfamily [mainface] [sans] [Optima] \definefontfamily [mainface] [mono] [dejavusansmono] [scale=0.865] %dejavumono/optima x-height ratio \definefontfamily [mainface] [math] [TeX Gyre Pagella Math] \setupbodyfont[mainface,11pt] neither \it nor \bf (italic and bold) variants are working in the body text (but are just rendered in the regular \rm font). when using \definefontfamily [mainface] [serif] [ebgaramond] instead, \it _does_ work, while \bf is not available. _this_ I might understand since there seems to be no bold variant of that font in the texlive distro (only 'regular' and 'italic'. but I would have thought that the different variants (italic, bold) can always be expected to just work if they are present (as they are for `optima')? joerg

Pablo

-- Using Opera's revolutionary email client: http://www.opera.com/mail/

On Sun, 21 Dec 2014 22:39:02 +0100, Wolfgang Schuster wrote:

...

but I'm already stumbling about the next thing. while playing around with some nice fonts I also tried out `optima' (like palatino by h. zapf). so that is what I see:

mtxrun --script font --list --all --name --pattern=*optima*

optima optimaextrablack /System/Library/Fonts/Optima.ttc index: 0 optimablack optimaextrablack /System/Library/Fonts/Optima.ttc index: 0 optimabold optimabold /System/Library/Fonts/Optima.ttc index: 3 optimabolditalic optimabolditalic /System/Library/Fonts/Optima.ttc index: 1 optimaextrablack optimaextrablack /System/Library/Fonts/Optima.ttc index: 0 optimaitalic optimaitalic /System/Library/Fonts/Optima.ttc index: 2 optimanormal optimaitalic /System/Library/Fonts/Optima.ttc index: 2 optimaregular optimaregular /System/Library/Fonts/Optima.ttc index: 4

then, when using, e.g.,

\definefontfamily [mainface] [serif] [Optima] \definefontfamily [mainface] [sans] [Optima] \definefontfamily [mainface] [mono] [dejavusansmono] [scale=0.865] %dejavumono/optima x-height ratio \definefontfamily [mainface] [math] [TeX Gyre Pagella Math] \setupbodyfont[mainface,11pt]

neither \it nor \bf (italic and bold) variants are working in the body text (but are just rendered in the regular \rm font).

I guess your context version is too old because the current version in the standalone installation of context shows the italic and bold styles.

I use mtx-context | ConTeXt Process Management 0.60 mtx-context | mtx-context | main context file: /opt/local/share/texmf-texlive/tex/context/base/context.mkiv mtx-context | current version: 2014.05.21 22:04 do you have any idea whether this already is 'too old'? if it is: is it recommendable to actually install standalone context beside/instead of the version included in texlive? (I mean, if the actual goal is to write some documents rather than diving deep into context for its own sake ;-))

Wolfgang

-- Using Opera's revolutionary email client: http://www.opera.com/mail/

On Sun, 21 Dec 2014 22:56:42 +0100, Wolfgang Schuster wrote:

...

Am 21.12.2014 um 22:45 schrieb j. van den hoff :

...

I guess your context version is too old because the current version in the standalone installation of context shows the italic and bold styles.

I use

mtx-context | ConTeXt Process Management 0.60 mtx-context | mtx-context | main context file: /opt/local/share/texmf-texlive/tex/context/base/context.mkiv mtx-context | current version: 2014.05.21 22:04

do you have any idea whether this already is 'too old'? if it is: is it recommendable to actually install standalone context beside/instead of the version included in texlive? (I mean, if the actual goal is to write some documents rather than diving deep into context for its own sake ;-))

Yes this version is too old, you need a context from august or later.

I'll try that. thank you joerg

Wolfgang

-- Using Opera's revolutionary email client: http://www.opera.com/mail/

On 12/22/2014 12:12 AM, j. van den hoff wrote:

OK, I've just installed the standalone version and adjusted my search path. now the very same document does no longer compile. I get the error:

8<--------------------------- ! Undefined control sequence

<recently read> \doctitle

l.106 \doctitle 8<--------------------------- where `doctitle' is defined in a small bare bones module (co-existing in the same dir as the doc) for setting up a title page. I guess I'm hitting some (context-) searchpath issue here that already is taken care of in the texlive distro? any help'd be appreciated.

From what I understand of your description, when the module is located in the same directory as the source document you compile, ConTeXt doesn’t need to search anything. But you need to compile it from that

Hi Jörg, providing a minimal sample that reproduces the error (at least, in your computer) avoids the guesswork :-). I think it is better that you start a new thread for this (new) issue. It will help others to search when facing similar problems. directory. BTW, is your module similar to the one suggested in http://wiki.contextgarden.net/Document_Titles#In_ConTeXt:_A_more_reusable_so... Pablo -- http://www.ousia.tk

Am 22.12.2014 um 00:12 schrieb j. van den hoff :

OK, I've just installed the standalone version and adjusted my search path. now the very same document does no longer compile. I get the error:

8<--------------------------- ! Undefined control sequence

<recently read> \doctitle

l.106 \doctitle 8<--------------------------- where `doctitle' is defined in a small bare bones module (co-existing in the same dir as the doc) for setting up a title page. I guess I'm hitting some (context-) searchpath issue here that already is taken care of in the texlive distro? any help'd be appreciated.

I guess you load the file with your definitions with the \usemodule command. There has been a change a while ago and context expects now a prefix when you load a module (e.g. p-<myfile>.tex) and when you add now the prefix to your file context will be able to load it. Another solution is to add \enabledirectives[modules.permitunprefixed] before the \usemodule command in your document, the command above tells context to also look for modules without a prefix as last resort. Wolfgang

Am 23.12.2014 um 14:15 schrieb j. van den hoff :

On Mon, 22 Dec 2014 22:35:43 +0100, Wolfgang Schuster mailto:schuster.wolfgang@gmail.com> wrote:

...

...

Am 22.12.2014 um 00:12 schrieb j. van den hoff :

OK, I've just installed the standalone version and adjusted my search path. now the very same document does no longer compile. I get the error:

8<--------------------------- ! Undefined control sequence

<recently read> \doctitle

l.106 \doctitle 8<--------------------------- where `doctitle' is defined in a small bare bones module (co-existing in the same dir as the doc) for setting up a title page. I guess I'm hitting some (context-) searchpath issue here that already is taken care of in the texlive distro? any help'd be appreciated.

I guess you load the file with your definitions with the \usemodule command.

correct.

...

There has been a change a while ago and context expects now a prefix when you load a module (e.g. p-<myfile>.tex) and when you add now the prefix to your file context will be able to load it. Another solution is to add

\enabledirectives[modules.permitunprefixed]

before the \usemodule command in your document, the command above tells context to also look for modules without a prefix as last resort.

yes, this one did the trick. thanks a lot. regarding the prefix handling/recognition, I don't quite get it (_what_ is considered a prefix, e.g. is there a canonical prefix separator etc. or where do I define the prefix?). I'll try to hunt for it on contextgarden. if you do have a pointer, though, that'd be nice.

http://wiki.contextgarden.net/Modules#Usage http://wiki.contextgarden.net/Modules#Usage Wolfgang

Am 23.12.2014 um 14:29 schrieb j. van den hoff :

uups. I was to quick with my answer: in the meantime I did reset my $PATH variable in order to use the texlive-context version again. so adding the \enabledirectives[modules.permitunprefixed] and recompiling the document did not proof anything (stupid error...). so I have now retried with the current standalone `context' and -- alas! -- the `undefined control sequence' error does not go away. do be specifc:

-- document and module reside in the same directory

-- the module is residing in file `t-title.tex' and defines (upon others) `\doctitle'

-- the document loads the module with `\usemodule[title]' (which is now preceded by `\enabledirectives[modules.permitunprefixed]') and then uses `\doctitle' which triggers the error.

-- right now, the standalone `context' binary is at the very top of $PATH.

any ideas?

The ConTeXt suite includes a title module (when you install the third party modules) which is loaded instead of your own title module. The following example shows how you can use the module in your document. \usemodule[title] \starttext \placetitle [author=Ben Lee User, title=How to write a \tex{placetitle} command, date=\currentdate\space\currenttime] \dorecurse{6} {\startparagraph \input tufte\par \stopparagraph} \stoptext When you want to use your module instead of the third party module rename it from t-title.tex to p-title.tex. Wolfgang

On Sun, 21 Dec 2014 23:17:52 +0100, Pablo Rodriguez wrote:

On 12/21/2014 10:45 PM, j. van den hoff wrote:

...

[...] do you have any idea whether this already is 'too old'? if it is: is it recommendable to actually install standalone context beside/instead of the version included in texlive? (I mean, if the actual goal is to write some documents rather than diving deep into context for its own sake ;-))

You can always install the latest standalone version beside TeX Live.

good to know. I'll try that (as this seems the way to go as I've learned from wolfgang schuster's mail).

They are totally independent. I had both TeX Live and ConTeXt Standalone. After I installed a new version of Linux, I didn’t have the need to reinstall TeX Live ;-).

Just in case it helps,

sure did! joerg

Pablo

-- Using Opera's revolutionary email client: http://www.opera.com/mail/