.
\enableexperiments[fonts.compact]
\definefontfamily[mainface][rm][TeX Gyre Termes]
[it={style:regular, features:{default,slanted}},
sl={style:regular, features:{default,slanted}}]
\setupbodyfont[mainface]
\starttext
\startstyle[style=italic]normal {\em emphasized} normal\stopstyle
\stoptext
The
[mainface][rm][TeX Gyre Termes]
[it={style:regular, features:{default,slanted}},
sl={style:regular, features:{default,slanted}}]
\setupbodyfont[mainface]
\starttext
\startstyle[style=italic]normal {\em emphasized} normal\stopstyle
\stoptext
The only way to mask the effect is to create a new
umulate, like
> [...]
> which you will now wikify...
Many thanks for your reply, Hans.
I will wikify this, once I figure out where it can fit in the wiki (in
due time, since ConTeXt is more and more complex for me lately and my
free time is less and less these days).
I only used \enableexpe
On 3/10/2024 9:32 AM, Pablo Rodriguez via ntg-context wrote:
On 3/9/24 16:04, Wolfgang Schuster wrote:
Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 19:39:
[...]
\enableexperiments[fonts.compact]
Which seeems weird to me. Or at least, I thought I read that Hans
enabled it by def
On 3/9/24 16:04, Wolfgang Schuster wrote:
> Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 19:39:
>> [...]
>>\enableexperiments[fonts.compact]
>>
>> Which seeems weird to me. Or at least, I thought I read that Hans
>> enabled it by default in LMTX.
>
> AFAIR Hans uses the setting in h
Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 19:39:
On 3/8/24 19:09, Wolfgang Schuster wrote:
Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 18:50:
[...]
LMTX gets b, c and d in slanted form.
LuaTeX gets only b and c in slanted form.
[...]
I get b and d in italic which i
On 3/8/24 19:09, Wolfgang Schuster wrote:
> Pablo Rodriguez via ntg-context schrieb am 08.03.2024 um 18:50:
>> [...]
>> LMTX gets b, c and d in slanted form.
>>
>> LuaTeX gets only b and c in slanted form.
> [...]
> I get b and d in italic which is the expected output.
Sorry, my LuaTeX is getting
={style: regular, features:{default, quality, slanted}},
sl={style: regular, features:{default, quality, slanted}}]
\setupbodyfontenvironment
[default]
[em=italic]
\setupbodyfont[mainface]
\starttext
\startTEXpage[offset=1em]
a\\
\em b\\
\em c\\
\em d
={style: regular, features:{default, quality, slanted}},
sl={style: regular, features:{default, quality, slanted}}]
\setupbodyfontenvironment
[default]
[em=italic]
\setupbodyfont[mainface]
\starttext
\startTEXpage[offset=1em]
a\\
\em b\\
\em c\\
\em d
: regular, features:{default, quality, slanted}}]
\setupbodyfontenvironment
[default]
[em=italic]
\setupbodyfont[mainface]
\starttext
\startTEXpage[offset=1em]
a\\
\em b\\
\em c\\
\em d\\
\stopTEXpage
\stoptext
LMTX gets b, c and d in slanted form.
LuaTeX gets only
Mikael, Wolfgang:
This is in reference to the prior
Re: redefine space to be the same as \␣ similar to knuthian approach
> Maybe your system is broken?
>
> >
> > > 2. The example below results in a correct output for \TEX.
> > >
> >
> > Not in my end with any font other than latin modern
>
On Fri, 01 Mar 2019 11:17:56 +0100 Hans Hagen wrote
> On 2/28/2019 12:38 PM, Marcel Krüger wrote:
> > On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
> >> As reported on the dev-luatex list --- is converted to an en-dash
> >> (instead of em-dash) if the
On 3/1/2019 1:15 PM, Ulrike Fischer wrote:
TeXLive is frozen and pretest has begun, so I don't see a danger to
apply patches now.
binaries get frozen at 22/3 and context isn't checked in yet (comes
after first binary generation)
anyway, i'll look at it (maybe this weekend)
Hans
Am Fri, 1 Mar 2019 11:17:56 +0100 schrieb Hans Hagen:
> it looks ok in context
You need to set automatichyphenmode=0 to see the problem in context:
the handling of the --- ligature is clearly broken in some cases:
\starttext
\automatichyphenmode=0
A---B A --- B
\stoptext
> Hm, I don't see tho
sh
> >> (instead of em-dash) if there are no spaces around the ---.
> >>
> >> We could now reproduce the problem also with the generic fontloader:
> >> it appears only with mode=node. I'm using the files from 2019-02-14,
> >> but the probl
On 2/28/2019 12:38 PM, Marcel Krüger wrote:
On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
We could now reproduce the problem also with the generic fontloader:
it appears
On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
> As reported on the dev-luatex list --- is converted to an en-dash
> (instead of em-dash) if there are no spaces around the ---.
>
> We could now reproduce the problem also with the generic fontloader:
> it appears only with mode=node
en is not so large and when my eyes
tire. If -- wouldn't work I would resort to a command like \ndash
instead only to get a better visual clue what's in the document.
But regardless from the input method. How can one enable a line
break after an em-dash when \automichyphenmode is 1? The o
t; editor, even more if the screen is not so large and when my eyes
> tire. If -- wouldn't work I would resort to a command like \ndash
> instead only to get a better visual clue what's in the document.
>
> But regardless from the input method. How can one enable a line
> b
ditor, even more if the screen is not so large and when my eyes
> tire. If -- wouldn't work I would resort to a command like \ndash
> instead only to get a better visual clue what's in the document.
>
> But regardless from the input method. How can one enable a line
> brea
rk I would resort to a command like \ndash
instead only to get a better visual clue what's in the document.
But regardless from the input method. How can one enable a line
break after an em-dash when \automichyphenmode is 1? The only way I
found is to explicitly insert a penalty:
\starttext
\
On 2/23/2019 4:30 PM, Ulrike Fischer wrote:
Am Sat, 23 Feb 2019 15:55:53 +0100 schrieb Hans Hagen:
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
in context we set:
\automatichyphenmode=1
This solves the
Am Sat, 23 Feb 2019 15:55:53 +0100 schrieb Hans Hagen:
>> As reported on the dev-luatex list --- is converted to an en-dash
>> (instead of em-dash) if there are no spaces around the ---.
> in context we set:
> \automatichyphenmode=1
This solves the problem and after some
On 2/23/2019 1:50 PM, Ulrike Fischer wrote:
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
We could now reproduce the problem also with the generic fontloader:
it appears only with mode=node. I'm using the files
As reported on the dev-luatex list --- is converted to an en-dash
(instead of em-dash) if there are no spaces around the ---.
We could now reproduce the problem also with the generic fontloader:
it appears only with mode=node. I'm using the files from 2019-02-14,
but the problem appeared fir
On 5/15/2017 8:27 PM, Pablo Rodriguez wrote:
On 05/15/2017 03:52 PM, Hans Hagen wrote:
On 5/14/2017 8:21 PM, Pablo Rodriguez wrote:
[...]
Select all, copy and paste it on a pure-text editor. You will get two
and four hyphens for en and em dashes, respectively.
Could you confirm this? Until
On 05/15/2017 03:52 PM, Hans Hagen wrote:
> On 5/14/2017 8:21 PM, Pablo Rodriguez wrote:
>> [...]
>> Select all, copy and paste it on a pure-text editor. You will get two
>> and four hyphens for en and em dashes, respectively.
>>
>> Could you confirm this? Until
t=1em]
-- ---
– —
\stopTEXpage
\stoptext
Select all, copy and paste it on a pure-text editor. You will get two
and four hyphens for en and em dashes, respectively.
Could you confirm this? Until very recently, I copied en and em dashes
from PDF documents generated by ConTeXt.
it has to do with more aggre
cument (it also happens with
> your attached PDF file):
>
> \starttext
> \startTEXpage[offset=1em]
> -- ---
>
> – —
> \stopTEXpage
> \stoptext
>
> Select all, copy and paste it on a pure-text editor. You will get two
> and four hyphens for en and
\stopTEXpage
\stoptext
Select all, copy and paste it on a pure-text editor. You will get two
and four hyphens for en and em dashes, respectively.
Could you confirm this? Until very recently, I copied en and em dashes
from PDF documents generated by ConTeXt.
Many thanks for your help,
I confirm the issue in NOT present in my machine (Arch Linux x64). I can
see the dashes as they are supposed to be.
Andrés Conrado Montoya
http://chiquitico.org
___
If your question is of interest to others as well, pl
It works flawless in arch linux 64bits.
___
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 :
On Thu, May 11, 2017 at 9:04 PM, Pablo Rodriguez wrote:
> On 05/11/2017 04:17 PM, Thomas Floeren wrote:
>>> On 9. May 2017, at 21:10, Pablo Rodriguez wrote:
>>> [...]
>>> Ligatures aren’t converted and even real en and em dashes are converted
>>> to hyphens.
On 05/11/2017 04:17 PM, Thomas Floeren wrote:
>> On 9. May 2017, at 21:10, Pablo Rodriguez wrote:
>> [...]
>> Ligatures aren’t converted and even real en and em dashes are converted
>> to hyphens.
>>
>> Could anyone confirm the issue?
>
> Works as expect
>\stoptext
>
> I get as result:
>
>--
>--
>
> Ligatures aren’t converted and even real en and em dashes are converted
> to hyphens.
>
> Could anyone confirm the issue?
Works as expected here, with ConTeXt 2017.05.10 10:41
Best,
Tom
&
Dear list,
using latest beta from 2017.05.09 10:14 with the following sample:
\starttext
\startTEXpage[offset=1em]
-- ---
– —
\stopTEXpage
\stoptext
I get as result:
--
--
Ligatures aren’t converted and even real en and em dashes are converted
to
On 3/31/2017 11:52 AM, Marco Patzer wrote:
On Fri, 31 Mar 2017 11:46:00 +0300
Kostirya wrote:
Two hyphens do not replaced on em—dash when dejavu,14pt
Use the tlig font feature
\definefontfeature
[tlig]
[default]
[tlig=yes]
\definefontfeature
[default]
[default
t;
>> Two hyphens do not replaced on em—dash when dejavu,14pt
>
> Use the tlig font feature
>
> \definefontfeature
> [tlig]
> [default]
> [tlig=yes]
>
> Marco
> ___
> I
On Fri, 31 Mar 2017 11:46:00 +0300
Kostirya wrote:
> Two hyphens do not replaced on em—dash when dejavu,14pt
Use the tlig font feature
\definefontfeature
[tlig]
[default]
[tlig=yes]
Marco
___
If y
No, It is not worked.
I mistakenly used a Unicode character in another test.
2017-03-31 12:13 GMT+03:00 Kostirya :
> I apologize.
> It is not hyphen symbol. It is unicode.
> Everything is working!
>
> 2017-03-31 11:46 GMT+03:00 Kostirya :
>> Hello.
>> Two hyphens do n
I apologize.
It is not hyphen symbol. It is unicode.
Everything is working!
2017-03-31 11:46 GMT+03:00 Kostirya :
> Hello.
> Two hyphens do not replaced on em—dash when dejavu,14pt
> :-(
>
>
>
> \starttext
> 1-2 11--22
>
> \switchtobodyfont[dejavu,14
Hello.
Two hyphens do not replaced on em—dash when dejavu,14pt
:-(
\starttext
1-2 11--22
\switchtobodyfont[dejavu,14pt]
1-2 11--22
\stoptext
___
If your question is of interest to others as well, please add an
On 12/20/2015 5:06 PM, Pablo Rodriguez wrote:
Dear list,
after upgrading to beta from 2015.12.20 00:29, I don’t get dashes in the
following sample:
\starttext
\startTEXpage[offset=1em]
en--dash: --\\
em---dash: ---
\stopTEXpage
\stoptext
It worked fine with beta
Dear list,
after upgrading to beta from 2015.12.20 00:29, I don’t get dashes in the
following sample:
\starttext
\startTEXpage[offset=1em]
en--dash: --\\
em---dash: ---
\stopTEXpage
\stoptext
It worked fine with beta from 2015.11.19 19:13.
I’m afraid this may be a bug
On 07/14/2015 07:11 PM, Hans Hagen wrote:
> On 7/14/2015 3:42 PM, Pablo Rodriguez wrote:
>> Hans,
>>
>> checking beta from 2015.07.12 23:30 in Win7 64bit works fine (ligatures,
>> no ligatures and dashes) with newotf.
>>
>> But I’m afraid that beta from 2015.07.14 10:37 doesn’t work disabling
>> li
On 7/14/2015 3:42 PM, Pablo Rodriguez wrote:
On 07/14/2015 12:54 PM, Rik Kabel wrote:
On 2015-07-12 12:52, Hans Hagen wrote:
[...]
i just checked the distribution on a vm and it works ok so best first
figure out why the tex ligs don't show up (when that relevant file is
not loaded well other ov
On 07/14/2015 12:54 PM, Rik Kabel wrote:
> On 2015-07-12 12:52, Hans Hagen wrote:
>> [...]
>> i just checked the distribution on a vm and it works ok so best first
>> figure out why the tex ligs don't show up (when that relevant file is
>> not loaded well other overloads might also fail so that c
that this sample doesn’t work with latest beta either:
\usemodule[newotf]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I
beta either:
\usemodule[newotf]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType
]
\definefontfeature[noliga][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType feature is
related to the non-activated em
On 07/12/2015 05:57 PM, Hans Hagen wrote:
> On 7/12/2015 5:27 PM, Pablo Rodriguez wrote:
>> [...]
>> Hi Otared,
>>
>> many thanks for your reply.
>>
>> Which is your OS and architecture?
>
> you use m-newotf from the distribution?
I use the one installed after updating the beta.
I have just chec
On 7/12/2015 5:27 PM, Pablo Rodriguez wrote:
On 07/12/2015 05:17 PM, Otared Kavian wrote:
Hi Pablo,
On my installation everything seems to work fine: Context
version 2015.07.12 15:40
Hi Otared,
many thanks for your reply.
Which is your OS and architecture?
you use m-newotf from the distri
On 07/12/2015 05:17 PM, Otared Kavian wrote:
> Hi Pablo,
>
> On my installation everything seems to work fine: Context
> version 2015.07.12 15:40
Hi Otared,
many thanks for your reply.
Which is your OS and architecture?
Many thanks again,
Pablo
--
http://www.ousia.tk
___
On 07/12/2015 05:04 PM, Axel Kielhorn wrote:
>> Am 12.07.2015 um 16:38 schrieb Pablo Rodriguez:
>> [...]
>> To the list members: could you test the sample above and tell em- and
>> en-dashes work and if no-liga disables ligatures? Adding architecture
>> may help.
>
EXpage[offset=1em] fiflff no--liga: \addfeature[noliga]fiflff --- em--dash \stopTEXpage \stoptextI may be wrong, but I think that the non-deactivated OpenType feature isrelated to the non-activated em- and en-dashes.To the list members: could you test the sample above and tell em- anden-
le doesn’t work with latest beta either:
>
>\usemodule[newotf]
>
>\definefontfeature[noliga][liga=no]
>
>\starttext
>\startTEXpage[offset=1em]
> fiflff no--liga:
>\addfeature[noliga]fiflff
>
>--- em--dash
>\stopTEXpage
>
][liga=no]
\starttext
\startTEXpage[offset=1em]
fiflff no--liga:
\addfeature[noliga]fiflff
--- em--dash
\stopTEXpage
\stoptext
I may be wrong, but I think that the non-deactivated OpenType feature is
related to the non-activated em- and en-dashes.
To the list members:
On 7/12/2015 12:49 PM, Pablo Rodriguez wrote:
On 07/12/2015 11:33 AM, Hans Hagen wrote:
On 7/12/2015 6:55 AM, Pablo Rodriguez wrote:
[...]
May the different behaviour caused by the fact that you use
LuaTeX-0.80.1 (as displayed in
http://www.pragma-ade.com/general/qrcs/setup-en.pdf) and we have
On 07/12/2015 11:33 AM, Hans Hagen wrote:
> On 7/12/2015 6:55 AM, Pablo Rodriguez wrote:
>> [...]
>> May the different behaviour caused by the fact that you use
>> LuaTeX-0.80.1 (as displayed in
>> http://www.pragma-ade.com/general/qrcs/setup-en.pdf) and we have
>> LuaTeX-0.80?
>
> i can't imagine
On 7/12/2015 6:55 AM, Pablo Rodriguez wrote:
On 07/11/2015 11:55 PM, Rik Kabel wrote:
On 2015-07-11 17:30, Hans Hagen wrote:
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
[...]
I discovered that em- and en-dashes aren’t enabled by default.
Is this intended?
works ok here
Hmmm. Fails
On 07/11/2015 11:55 PM, Rik Kabel wrote:
> On 2015-07-11 17:30, Hans Hagen wrote:
>> On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
>>> Hans,
>>> [...]
>>> I discovered that em- and en-dashes aren’t enabled by default.
>>>
>>> Is this intended?
On 2015-07-11 17:30, Hans Hagen wrote:
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
with the following sample:
\usemodule[newotf]
%~ \setupbodyfont
%~ [palatino]
\starttext
--- em--dash (with en--dash inside)
\stoptext
I discovered that em- and en
On 7/11/2015 5:09 PM, Pablo Rodriguez wrote:
Hans,
with the following sample:
\usemodule[newotf]
%~ \setupbodyfont
%~ [palatino]
\starttext
--- em--dash (with en--dash inside)
\stoptext
I discovered that em- and en-dashes aren’t enabled by default.
Is this
Hans,
with the following sample:
\usemodule[newotf]
%~ \setupbodyfont
%~ [palatino]
\starttext
--- em--dash (with en--dash inside)
\stoptext
I discovered that em- and en-dashes aren’t enabled by default.
Is this intended?
Many thanks for your help,
Pablo
How about
Most newspapers |<|and all that follow AP style|>| insert a space
before and after the em dash.
Might I suggest that this could/should be set|-|up in Polish to repeat
the (second) emdash if it is followed by a line break?
Alan
On Mon, 2 Mar 2015 10:02:53 +0100
Hans Hagen
On 3/1/2015 8:34 PM, Piotr Kopszak wrote:
Many Thanks Hans!
But that's not exactly what I need, sorry for being imprecise, I do
not need to repeat hyphens, but only em dashes (or en dashes, which
ever are used in the document) in situations like this.
Most newspapers — and all that foll
Many Thanks Hans!
But that's not exactly what I need, sorry for being imprecise, I do
not need to repeat hyphens, but only em dashes (or en dashes, which
ever are used in the document) in situations like this.
Most newspapers — and all that follow AP style — insert a space before
and afte
On 3/1/2015 5:41 PM, Piotr Kopszak wrote:
Hello list,
This is probably a Polish idiosyncrasy, but we have to live with it.
According to punctuation rules when an em dash is at the end of a
line, it should be repeated at the beginning of the next one (true, it
is often disregarded due to lack of
Hello list,
This is probably a Polish idiosyncrasy, but we have to live with it.
According to punctuation rules when an em dash is at the end of a
line, it should be repeated at the beginning of the next one (true, it
is often disregarded due to lack of support for it in typesetting
programs). Is
On Tue, Aug 20, 2013 at 02:00:16PM +0200, Hans Hagen wrote:
> great ... another non standard use of names
There are no standard glyph names for TrueType/OpenType fonts. AGL is
completely optional, and is not part of any standard. Fonts can, and do,
use names that does not follow AGL (or no names a
On 8/20/2013 2:07 PM, Martin Moncrieffe wrote:
Hi Matt,
On 20 Aug 2013, at 13:00, Matt Gushee mailto:m...@gushee.net>> wrote:
I don't think it's the font. I have been trying to produce an em dash
using the latest stable release from contextgarden.net
<http://contextgarden.n
Hi Matt,
On 20 Aug 2013, at 13:00, Matt Gushee wrote:
> I don't think it's the font. I have been trying to produce an em dash
> using the latest stable release from contextgarden.net, with a couple
> of different fonts--Alegreya, which is a free OpenType font, Latin
> Mode
I don't think it's the font. I have been trying to produce an em dash
using the latest stable release from contextgarden.net, with a couple
of different fonts--Alegreya, which is a free OpenType font, Latin
Modern, and one other that I don't remember. In my case, regardless of
th
acOSX (10.8.4)
with ConTeXt 2013.05.28 from the TeXlive 2013 distribution. All
works, but unfortunately, em dashes are not typeset correctly;
there are three dashes instead of a continuous line.
The font (at least my version) does not contain an em dash in slot
U+2014.
I checked a different versi
On 2013–08–20 Martin Moncrieffe wrote:
> Finder reports that my version of Hoefler is 8.0d2e1.
This means we already have three different Hoefler versions in this
thread.
> […] shows the the em dash is present in the font.
When I use a version with em dash, your example works here. S
Hi Marko,
On 20 Aug 2013, at 10:52, Marco Patzer wrote:
>
> I checked a different version of the font (1.000) and it works. It
> seems you're using a version not containing an em dash.
Thanks for looking into this. Finder reports that my version of Hoefler is
8.0d2e1.
cOSX (10.8.4)
>>> with ConTeXt 2013.05.28 from the TeXlive 2013 distribution. All
>>> works, but unfortunately, em dashes are not typeset correctly;
>>> there are three dashes instead of a continuous line.
>>
>> The font (at least my version) does not cont
distribution. All
> > works, but unfortunately, em dashes are not typeset correctly;
> > there are three dashes instead of a continuous line.
>
> The font (at least my version) does not contain an em dash in slot
> U+2014.
I checked a different version of the font (1.000)
On 2013–08–19 Martin Moncrieffe wrote:
> Hopefully, this is the correct list for this question. I'm trying
> to typeset documents using the font Hoefler on MacOSX (10.8.4)
> with ConTeXt 2013.05.28 from the TeXlive 2013 distribution. All
> works, but unfortunately, em dashe
Hopefully, this is the correct list for this question. I'm trying to typeset
documents using the font Hoefler on MacOSX (10.8.4) with ConTeXt 2013.05.28
from the TeXlive 2013 distribution. All works, but unfortunately, em dashes
are not typeset correctly; there are three dashes instead
Am 02.04.2012 um 15:10 schrieb S Barmeier:
> On 04/02/2012 09:18 PM, Wolfgang Schuster wrote:
>>
>> Am 02.04.2012 um 11:37 schrieb S Barmeier:
>>
>>> My main font is Japanese and I'm falling back on a different font for
>>> Latin characters.
>>
On 04/02/2012 09:18 PM, Wolfgang Schuster wrote:
>
> Am 02.04.2012 um 11:37 schrieb S Barmeier:
>
>> My main font is Japanese and I'm falling back on a different font for
>> Latin characters.
>>
>> The \it switch works fine, but \em renders the Japanese f
Am 02.04.2012 um 11:37 schrieb S Barmeier:
> My main font is Japanese and I'm falling back on a different font for
> Latin characters.
>
> The \it switch works fine, but \em renders the Japanese font (e.g. page
> numbers in the index). Is there a way to have \em us
My main font is Japanese and I'm falling back on a different font for
Latin characters.
The \it switch works fine, but \em renders the Japanese font (e.g. page
numbers in the index). Is there a way to have \em use the italic (of the
fallback font)?
Thanks,
Se
Am 21.02.2012 um 13:05 schrieb Wolfgang Schuster:
> Am 21.02.2012 um 10:19 schrieb Alasdair McAndrew:
>
>> I discovered this by hunting through font-ini.mkii:
>>
>> \setupbodyfontenvironment [default] [em={\slanted\color[red]}]
>
> Better \setupbodyfontenvironm
Am 21.02.2012 um 10:19 schrieb Alasdair McAndrew:
> I discovered this by hunting through font-ini.mkii:
>
> \setupbodyfontenvironment [default] [em={\slanted\color[red]}]
Better \setupbodyfontenvironment[default][em={\sl\red}].
> Seems to work well. You see, I want to use the
I discovered this by hunting through font-ini.mkii:
\setupbodyfontenvironment [default] [em={\slanted\color[red]}]
Seems to work well. You see, I want to use the same ConTeXt files for two
purposes: to create a set of printable notes (without colour) and to make a
set of displayable onscreen
On Tue, 21 Feb 2012, Alasdair McAndrew wrote:
In some overheads I'm creating, I'd like emphasized text {\em like this} to
appear as red. I hoped that something like this would work:
\setupbodyfontenvironment[default][em={slanted, textcolor=red}]
but it doesn't. What is the c
In some overheads I'm creating, I'd like emphasized text {\em like this} to
appear as red. I hoped that something like this would work:
\setupbodyfontenvironment[default][em={slanted, textcolor=red}]
but it doesn't. What is the canonical way of obtaining red, emphasized
On 16-12-2011 00:31, Chris Lott wrote:
I found a bunch of code that sets up Minion Pro (and Myriad) typefaces that
seems to work (once I modified MinionPro-Italic and the rest to be MinionPro-It
as it is on my system:
http://pastebin.com/muSg4dZN
However, neither \em nor \slanted make any
I found a bunch of code that sets up Minion Pro (and Myriad) typefaces that
seems to work (once I modified MinionPro-Italic and the rest to be MinionPro-It
as it is on my system:
http://pastebin.com/muSg4dZN
However, neither \em nor \slanted make any change to the text. Since I'm
basi
2011/3/21 Ulrike Fischer
> Am Mon, 21 Mar 2011 10:51:44 +0100 schrieb Cecil Westerhof:
>
> > Until now I always used a - (minus sign) to define a sub sentence or for
> an
> > optional word, like:
> > This is -now- not necessary,
> >
> > I understood tha
Am Mon, 21 Mar 2011 10:51:44 +0100 schrieb Cecil Westerhof:
> Until now I always used a - (minus sign) to define a sub sentence or for an
> optional word, like:
> This is -now- not necessary,
>
> I understood that normally you use the em dash for this. But for only a
>
Until now I always used a - (minus sign) to define a sub sentence or for an
optional word, like:
This is -now- not necessary,
I understood that normally you use the em dash for this. But for only a
word, this seems a little big. Could I then use an en dash or should I keep
using a minus sign
On 25-2-2011 9:44, Procházka Lukáš Ing. - Pontex s. r. o. wrote:
... Thanks for the answers.
I'm familiar with using \dontleavehmode when needing to keep a figure
midaligned; I had no idea that this would be a similar situation (and
solution).
{\em xxx ..}
the first x triggers the start
ook to the following problem.
>
> I wonder why the behaviour described bellow occurs and how to typeset a
> paragraph starting with some text enclosed into {\em ...} group inside the
> "free" area formed (affected) by \placefigure.
>
> ---
>
> \starttext
>
09:16 schrieb Henning Hraban Ramm:
You can add a \strut in front of {\em - that’s a usual workaround for problems
with non-letters starting a paragraph.
The usual workaround is \dontleavehmode.
Wolfgang
--
Ing. Lukáš Procházka [mailto:l...@pontex.cz]
Pontex s. r. o. [mailto:pon...@pont
Am 25.02.2011 um 09:16 schrieb Henning Hraban Ramm:
> You can add a \strut in front of {\em - that’s a usual workaround for
> problems with non-letters starting a paragraph.
The usual workaround is \dontleavehmode.
Wo
to typeset a
> paragraph starting with some text enclosed into {\em ...} group inside the
> "free" area formed (affected) by \placefigure.
>
> ---
>
> \starttext
> \placefigure
>[left,none]
>{}
>{ \startMPcode
>draw (0,0)--(6cm,6cm);
>
.
{\em This empathized text starting a new paragraph} should not
scratch the picture left.
When some text contains {\em an empathized text inside the
paragraph}, text flows normally as expected.
\input tufte
\stoptext
---
You can add a \strut in front of {\em - that’s a usual workaround
1 - 100 of 146 matches
Mail list logo
