Hans,
thanks you for the solution to my font problem. I appreciate it.
I'm trying to understand the definefont command you used and it seems that the
arguments 'sa 1' in the macro is a size indication somewhat similar to 'at
10pt' but uses a relative size parameter as opposed to the
On 11/26/2021 12:59 PM, jdh via ntg-context wrote:
Here's my MWE:
Objective is to typeset a Chancery font text in the upper lefthand side
of a page, and
then do the main body in some normal font. Then at the very last print
a sign off in
Chancery. For some reason I
Here's my MWE:
Objective is to typeset a Chancery font text in the upper lefthand side
of a page, and
then do the main body in some normal font. Then at the very last print
a sign off in
Chancery. For some reason I can't get both to print out as Chancery.
Only one or the
On the same source file Texlive 2004 context
(mkiv) can find files that a more recent stand
alone version of context can't. I need to set
something somewhere so that the stand alone
version can find files in /usr/share/fonts/OTF.
I call the stand alone version from a script
called Context in
On 05/02/2015 04:19 PM, John Culleton wrote:
On the same source file Texlive 2004, context
Hi John,
sorry, but I wonder whether you meant TeX Live 2014.
(mkiv) can find files that a more recent stand
alone version of context can't.
Font files, I guess.
I need to set something somewhere so
On Fri, May 31, 2013 at 01:52:22PM +0200, H. Özoguz wrote:
Hi there,
I cant run the font ramnaclq-webfont.ttf (see attachment) in Context.
That is a broken, a so called “ASCII hack” font that (ab)uses ASCII code
points for Arabic. In short it is a broken font and will not work.
Regards,
Salaam, Huseyn,
On Fri, 31 May 2013 07:24:20 -0600, H. Özoguz h.oezo...@mmnetz.de wrote:
With the font file maddina.ttf I have the same problems. But this font
is clearly not broken, you can download it here:
http://www.searchfreefonts.com/free/quran-madina.htm (or see attachment
of this
Salaam Huseyin,
If you have not done so already, you can also try the Quran fonts listed
at the bottom of this page:
http://al-quran.info/page/about
Scheherazade you are already familiar with. I have not done much testing
of the others but they are all OT I believe.
Best wishes
Idris
--
Vasile Gaburici wrote:
Feel free to fiddle with the sort function if you name fonts
differently, but you need to make sure that bold italic gets loaded
before bold for the bug to occur.
Ok, bug found and squashed. Patch is below
Okay, I've updated to the latest beta. Recursive OSFONTDIR
Vasile Gaburici wrote:
If you still haven't figured out how to reproduce it, apply the
patched I've attached. It will force the hash entries to be added in
sorted order. With the patch applied, if you have some fonts called
Calibri Bold Italic.otf
Calibri Bold.otf
Calibri Italic.otf
On Aug 14, 2008, at 10:48 AM, Hans Hagen wrote:
the order is just one factor. what actually happens is that there is a
compensation for buggy font names (as happens often in afm files) so
in
practice one entry might become three entries; taco noticed that one
of
the fallbacks create
Vasile Gaburici wrote:
I've switched to the rsync-ed minimals on Linux. There are still some
problems with fonts:
1) Bold is still missing from fonts pulled via OSFONTDIR, e.g.:
verdana Verdana
/usr/share/fonts/vista/Verdana.ttf
verdana bold italic
Taco Hoekwater wrote:
Vasile Gaburici wrote:
I've switched to the rsync-ed minimals on Linux. There are still some
problems with fonts:
1) Bold is still missing from fonts pulled via OSFONTDIR, e.g.:
verdana Verdana
/usr/share/fonts/vista/Verdana.ttf
verdana
On Wed, Aug 13, 2008 at 11:31 AM, Hans Hagen [EMAIL PROTECTED] wrote:
Yes, recursion would be nice.
font-syn.lua, line 190:
path = input.clean_path(path .. /)
path = path:gsub(/+,/)
path = path .. **/
insert the last line and see what happens (untested because
Vasile Gaburici wrote:
On Wed, Aug 13, 2008 at 11:31 AM, Hans Hagen [EMAIL PROTECTED] wrote:
Yes, recursion would be nice.
font-syn.lua, line 190:
path = input.clean_path(path .. /)
path = path:gsub(/+,/)
path = path .. **/
insert the last line and see what
As for the missing bold, it seems there's a bug in the naming scheme:
Ii the bold italic file gets read from the disk before the bold, then
you don't get the right entries. It so happens that most of the fonts
in that dir had bold before bold italic, e.g.
fontnames | identifying ttf font
Vasile Gaburici wrote:
As for the missing bold, it seems there's a bug in the naming scheme:
Ii the bold italic file gets read from the disk before the bold, then
you don't get the right entries. It so happens that most of the fonts
in that dir had bold before bold italic, e.g.
fontnames |
On Wed, Aug 13, 2008 at 2:20 PM, Hans Hagen [EMAIL PROTECTED] wrote:
Vasile Gaburici wrote:
As for the missing bold, it seems there's a bug in the naming scheme:
Ii the bold italic file gets read from the disk before the bold, then
you don't get the right entries. It so happens that most of
Vasile Gaburici wrote:
I've switched to the rsync-ed minimals on Linux. There are still some
problems with fonts:
1) Bold is still missing from fonts pulled via OSFONTDIR, e.g.:
verdana Verdana
/usr/share/fonts/vista/Verdana.ttf
verdana bold italic
On Wed, Aug 13, 2008 at 1:47 PM, Vasile Gaburici [EMAIL PROTECTED] wrote:
On Wed, Aug 13, 2008 at 2:20 PM, Hans Hagen [EMAIL PROTECTED] wrote:
Vasile Gaburici wrote:
As for the missing bold, it seems there's a bug in the naming scheme:
Ii the bold italic file gets read from the disk before
Before I get anymore strawman arguments, here's the definitive experiment:
$ ls -U1 /usr/share/fonts/vista/ | grep erda
Verdanai.ttf
Verdana.ttf
Verdanaz.ttf
Verdanab.ttf
$ ls -U1 /xp/wtf/
Verdana.ttf
Verdanab.ttf
Verdanai.ttf
Verdanaz.ttf
Notice that the directory order is different, bold
Vasile Gaburici wrote:
Before I get anymore strawman arguments, here's the definitive experiment:
$ ls -U1 /usr/share/fonts/vista/ | grep erda
Verdanai.ttf
Verdana.ttf
Verdanaz.ttf
Verdanab.ttf
$ ls -U1 /xp/wtf/
Verdana.ttf
Verdanab.ttf
Verdanai.ttf
Verdanaz.ttf
did you test the
Vasile Gaburici wrote:
Before I get anymore strawman arguments, here's the definitive experiment:
As Hans said, should be corrected in the latest beta. Please cut us some
slack here, debugging unreproducible problems is hard and timeconsuming.
BTW, the Lua 5.1 reference manual is a joke.
On Wed, Aug 13, 2008 at 8:00 PM, Taco Hoekwater [EMAIL PROTECTED] wrote:
Vasile Gaburici wrote:
Before I get anymore strawman arguments, here's the definitive experiment:
As Hans said, should be corrected in the latest beta. Please cut us some
slack here, debugging unreproducible problems is
If you still haven't figured out how to reproduce it, apply the
patched I've attached. It will force the hash entries to be added in
sorted order. With the patch applied, if you have some fonts called
Calibri Bold Italic.otf
Calibri Bold.otf
Calibri Italic.otf
Calibri.otf
the order of hash
I've switched to the rsync-ed minimals on Linux. There are still some
problems with fonts:
1) Bold is still missing from fonts pulled via OSFONTDIR, e.g.:
verdana Verdana
/usr/share/fonts/vista/Verdana.ttf
verdana bold italic Verdana Bold Italic
Johan Blixt-Dackhammar wrote:
I updated ConTeXt to the latest version available in i-Installer and
the error dissapeared. Although, another thing started to mess upp. I
write my documents in UTF-8 and was before upgrading using the
\enableregime[utf] commande which worked perfect. After
Okay, perhaps it's a font related error. I can't say that I do
understand much of the log, but I saw something saying that there was
an error trying to load a font. Here's the full LOG:
TeXExec 5.4.3 - ConTeXt / PRAGMA ADE 1997-2005
fixing engine variable : pdfetex
executable :
Johan Blixt-Dackhammar wrote:
Okay, perhaps it's a font related error. I can't say that I do
understand much of the log, but I saw something saying that there was
an error trying to load a font. Here's the full LOG:
This is quickly becoming a FAQ:
Johan Blixt-Dackhammar wrote:
Trying that rendered the same result, but thanks anyway...
On 6/1/06, Otared Kavian [EMAIL PROTECTED] wrote:
On 31 mai 2006, at 23:40, Johan Blixt-Dackhammar wrote:
When trying to typeset for example a document using the mag-01 module
I get an error
I updated ConTeXt to the latest version available in i-Installer and
the error dissapeared. Although, another thing started to mess upp. I
write my documents in UTF-8 and was before upgrading using the
\enableregime[utf] commande which worked perfect. After upgrading
though, I only get blanks
When trying to typeset for example a document using the mag-01 module
I get an error that from what I understand is font related. I'm using
MacOS 10.4.6 (on intel), and I do have the Palatino font. Why do I get
the error and how can the problem be resolved?
ERROR
On 31 mai 2006, at 23:40, Johan Blixt-Dackhammar wrote:
When trying to typeset for example a document using the mag-01 module
I get an error that from what I understand is font related. I'm using
MacOS 10.4.6 (on intel), and I do have the Palatino font. Why do I get
the error and how can the
Trying that rendered the same result, but thanks anyway...
On 6/1/06, Otared Kavian [EMAIL PROTECTED] wrote:
On 31 mai 2006, at 23:40, Johan Blixt-Dackhammar wrote:
When trying to typeset for example a document using the mag-01 module
I get an error that from what I understand is font
Taco Hoekwater wrote:
Hi Hans,
(I am not really going to answer you, sorry).
I usually ignore those cannot find encoding-urw-family.map
messages (yes, I get them as well).
The needed font mapping lines for the 'base' postscript
fonts are also in encoding-base.map, and that file usually
is
Hans van der Meer wrote:
Do I now understand correctly that I MUST use texfont first in order
to work with fonts in ConTeXt? I did not realize that when going over
to the new tetex setup. I guess the typescripts for the lm/cmr fonts
are ready-made in the context distribution?
not for
Two more questions:
(1) On Nov 14, 2005, at 0:07, Hans Hagen wrote:
Hans van der Meer wrote:
No help from enabling in cont-sys.tex of:
\usetypescript[adobekb] [\defaultencoding]
(updmap.cfg contains URWkb for the LW35 fonts)
then it starts asking for (non-existing) maps like:
Warning:
Hi Hans,
(I am not really going to answer you, sorry).
I usually ignore those cannot find encoding-urw-family.map
messages (yes, I get them as well).
The needed font mapping lines for the 'base' postscript
fonts are also in encoding-base.map, and that file usually
is found. The message is
I used to work with the TeX i-Package install. But every once in a
while tex has to be updated. Then I was confronted with fairly hefty
downloads for my humble isdn-telephone connection (not everyone has
adsl). That's the reason I switched over to installing teTeX and
ConTeXy directly. Not
Hans van der Meer wrote:
No help from enabling in cont-sys.tex of:
\usetypescript[adobekb] [\defaultencoding]
(updmap.cfg contains URWkb for the LW35 fonts)
then it starts asking for (non-existing) maps like:
Warning: pdfetex (file ec-urw-helvetica.map): cannot open font map file
that is when
40 matches
Mail list logo
