Hi, the following test file gives an error with the latest beta: \setupbodyfont[gentium,12pt] \starttext \buildtextaccent\greekdasia\greekalphamacron \stoptext it works with a somewhat older one (2013.12.30). The error is ! Missing number, treated as zero. system > tex > error on line 5 in file /tmp/test.tex: Missing number, treated as zero ... ... <to be read again> \relax \buildtextaccent ...umber \b_enco_accent )}\relax \ifcase \scratchcounter \e... l.5 \buildtextaccent\greekdasia\greekalphamacron I thought this pointed to enco-ini.mkiv, but the file is unchanged between these two versions, so I'm a bit baffled. All best Thomas
On 1/16/2014 11:23 PM, Thomas A. Schmitz wrote:
Hi,
the following test file gives an error with the latest beta:
\setupbodyfont[gentium,12pt]
\starttext \buildtextaccent\greekdasia\greekalphamacron \stoptext
it works with a somewhat older one (2013.12.30). The error is
! Missing number, treated as zero.
system > tex > error on line 5 in file /tmp/test.tex: Missing number, treated as zero ...
....
<to be read again> \relax \buildtextaccent ...umber \b_enco_accent )}\relax \ifcase \scratchcounter \e... l.5 \buildtextaccent\greekdasia\greekalphamacron
I thought this pointed to enco-ini.mkiv, but the file is unchanged between these two versions, so I'm a bit baffled.
no, side effect of substantial optimizations (where i simply couldn't test everything ... you're probably the only user building accents) 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 -----------------------------------------------------------------
On 2014-01-17 06:22, Hans Hagen wrote:
no, side effect of substantial optimizations (where i simply couldn't test everything ... you're probably the only user building accents)
Hans
It is needed to create what might otherwise be LATIN SMALL LETTER Q WITH ACUTE ACCENT as well. This is not a Unicode character, but is easily constructed as: \buildtextaccent\textacute q for use in setting, for example, this bit of Spinoza's /Tractatus Politicus/, in which it appears four times. The character was commonly used in Latin texts published from the 16th through the 19th century. The above was done with LaTeX (\csdef is from etoolbox) and the following preamble code: \DeclareTextAccent{\RKacute}{\UTFencname}{"00B4} \newcommand*{\RKqacute}{\RKacute q}% LATIN SMALL LETTER Q WITH ACUTE ACCENT % The following works, instead of the above, with Linux Libertine (and %+ probably many other fonts) but does not work with the IM Fell fonts, %+ which are missing glyph 0x301, COMBINING ACUTE ACCENT: % \csdef{RKacute}#1{#1\char"301} % \csdef{RKqacute}{\RKacute{q}} -- Rik Kabel
On 1/17/2014 5:04 PM, Rik Kabel wrote:
On 2014-01-17 06:22, Hans Hagen wrote:
no, side effect of substantial optimizations (where i simply couldn't test everything ... you're probably the only user building accents)
Hans
It is needed to create what might otherwise be LATIN SMALL LETTER Q WITH ACUTE ACCENT as well. This is not a Unicode character, but is easily constructed as:
\buildtextaccent\textacute q
for use in setting, for example, this bit of Spinoza's /Tractatus Politicus/, in which it appears four times. The character was commonly used in Latin texts published from the 16th through the 19th century.
The above was done with LaTeX (\csdef is from etoolbox) and the following preamble code:
\DeclareTextAccent{\RKacute}{\UTFencname}{"00B4} \newcommand*{\RKqacute}{\RKacute q}% LATIN SMALL LETTER Q WITH ACUTE ACCENT % The following works, instead of the above, with Linux Libertine (and %+ probably many other fonts) but does not work with the IM Fell fonts, %+ which are missing glyph 0x301, COMBINING ACUTE ACCENT: % \csdef{RKacute}#1{#1\char"301} % \csdef{RKqacute}{\RKacute{q}}
do we need a module with predefined 'missing from unicode' characters? ----------------------------------------------------------------- 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 -----------------------------------------------------------------
On Fri, Jan 17, 2014 at 7:11 PM, Hans Hagen wrote:
do we need a module with predefined 'missing from unicode' characters?
I don't think so. We can end up with a neverending and always incomplete list (with theoretically unlimited number of entries), usable only to those few people who will care to contribute. In my opinion such a list is pretty much useless. Unicode already specifies that one could use "q" followed by "combining acute". And TeX also has support for {\'q}. Everything else is private use, something that users might not even use in more than a single document. I don't see any advantage in creating an endless incomplete list. In all honesty it's a lot more useful/readable/straightforward to use {\'q} or proper Unicode in these cases. And if it's not comfortable enough for the user, he can always provide his own private definitions. Thomas and Rik most probably need just the existing mechanism to work properly. Well, it might be slightly different for Thomas where Ancient Greek has a limited set of letters, but then such a list should better be defined in an "ancient greek predefined characters module". Just my 2 cents. Mojca
On 1/17/2014 7:39 PM, Mojca Miklavec wrote:
On Fri, Jan 17, 2014 at 7:11 PM, Hans Hagen wrote:
do we need a module with predefined 'missing from unicode' characters?
I don't think so. We can end up with a neverending and always incomplete list (with theoretically unlimited number of entries), usable only to those few people who will care to contribute. In my opinion such a list is pretty much useless.
Unicode already specifies that one could use "q" followed by "combining acute". And TeX also has support for {\'q}. Everything else is private use, something that users might not even use in more than a single document. I don't see any advantage in creating an endless incomplete list. In all honesty it's a lot more useful/readable/straightforward to use {\'q} or proper Unicode in these cases. And if it's not comfortable enough for the user, he can always provide his own private definitions.
Thomas and Rik most probably need just the existing mechanism to work properly. Well, it might be slightly different for Thomas where Ancient Greek has a limited set of letters, but then such a list should better be defined in an "ancient greek predefined characters module".
the mechanisms works ok (i just made it a bit more efficient, not that it matters much)
Just my 2 cents.
it depends on to what extend such characters play a different role too and need to travel around (but as there never was any demand for that i assume 2 cents will do) 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 -----------------------------------------------------------------
On 01/17/2014 07:39 PM, Mojca Miklavec wrote:
Thomas and Rik most probably need just the existing mechanism to work properly. Well, it might be slightly different for Thomas where Ancient Greek has a limited set of letters, but then such a list should better be defined in an "ancient greek predefined characters module".
Mojca is right. These are special cases (for example metrical descriptions), and for me at least, it wouldn't make sense to predefine them since I may need slighly different definitions depending on font, purpose, etc. Thomas
I don't think so. We can end up with a neverending and always incomplete list (with theoretically unlimited number of entries), usable only to those few people who will care to contribute.
I couldn't agree more. Unicode already has mechanisms to encode just about any accented character, and OpenType has its own mechanisms to display them very accurately. It's best to use these standard features and an appropriate font. Arthur
participants (5)
-
Arthur Reutenauer -
Hans Hagen -
Mojca Miklavec -
Rik Kabel -
Thomas A. Schmitz