Am Wed, 19 Sep 2018 10:54:08 +0200 schrieb Hans Hagen:

On 9/19/2018 10:24 AM, Ulrike Fischer wrote:

...

Because of a question on tex.sx I tried to use the source han sans fonts. I installed (in windows 10) the fonts from this zip-file:

https://github.com/adobe-fonts/source-han-sans/blob/release/OTF/SourceHanSan...

Trying to use them with latex/luaotfload failed with a memory exhausted error while trying to write the lua-file. In context

\starttext \font\test={name:sourcehansans} \test abc \stoptext

gave the error:

fonts > otf loading > loading 'c:/windows/fonts/SourceHanSans-Regular.otf', hash 'sourcehansans-regular' otf reader > loading of table 'vorg' skipped otf reader > invalid index in single format 1: 65353 -> 67212 (max 65535) otf reader > rule 1 in gsub lookup 's_s_5' has empty lookups fonts > otf loading > loading failed due to read error fonts > defining > forced type 'otf' of 'c:/windows/fonts/SourceHanSans-Regular' not found fonts > defining > font with asked name 'c:/windows/fonts/SourceHanSans-Regular' is not found using lookup 'name' fonts > defining > unknown font 'c:/windows/fonts/SourceHanSans-Regular', loading aborted

xelatex had no problems to use the font.

Is this an error in the font or in the fontloader?

it works ok here with luatex

but ... do you use luajittex?

No (neither with lualatex). The context log says at the end: mkiv lua stats > used platform: mswin, type: windows, binary subtree: texmf-mswin mkiv lua stats > used engine: luatex version 1.09 with functionality level 6930, banner: this is luatex, version 1.09.0 (tex live 2018/w32tex) mkiv lua stats > control sequences: 45351 of 65536 + 100000 mkiv lua stats > lua properties: engine: lua 5.3, used memory: 1519 MB (ctx: 1460 MB), hash type: lua, hash chars: min(32,40), symbol mask: utf (τεχ) mkiv lua stats > runtime: 39.711 seconds The fonts *are* large, and my computer is quite old, so it could be a hardware problem, but I'm wondering a bit about the message

otf reader > invalid index in single format 1: 65353 -> 67212

-- Ulrike Fischer http://www.troubleshooting-tex.de/

Hi, Here is what I get (ConTeXt ver: 2018.09.13 17:41 MKIV beta, luatex 1.09): fonts > otf loading > loading '/Users/taco/context-maps/tex/texmf-fonts/fonts/data/SourceHanSans-Regular.otf', hash 'sourcehansans-regular' otf reader > loading of table 'vorg' skipped otf reader > invalid index in single format 1: 65353 -> 67212 (max 65535) otf reader > rule 1 in gsub lookup 's_s_5' has empty lookups otf reader > merging 3 steps of 'gpos_single' lookup 'p_s_0' otf reader > merging 2 steps of 'gpos_pair' lookup 'p_s_1' otf reader > turning pairs of step 1 of 'gpos_pair' lookup 'p_s_1' into kerns otf reader > merging 11 steps of 'gpos_single' lookup 'p_s_2' otf reader > merging 3 steps of 'gpos_single' lookup 'p_s_3' otf reader > merging 10 steps of 'gpos_single' lookup 'p_s_5' otf reader > 24 steps of 351 removed due to merging otf reader > 1 steps of 351 steps turned from pairs into kerns otf reader > duplicates: 33 : [null] @ I00001 [soh] [stx] [etx] [eot] [enq] [ack] [bel] [bs] [ht] [lf] [vt] [ff] [cr] [so] [si] [dle] [dc1] [dc2] [dc3] [dc4] [nak] [syn] [etb] [can] [em] ... otf reader > duplicates: 1 :   (U+02002) @ I0F63F ﾠ (U+0FFA0) … lots more duplicates and a successful run despite all that. Note, however, that the luatex process tops out at nearly 3GB RAM use while generating the cached version, which could be a problem on 32-bit operating systems. Best wishes, Taco

On 19 Sep 2018, at 11:21, luigi scarso wrote:

On Wed, Sep 19, 2018 at 11:18 AM Ulrike Fischer wrote: Am Wed, 19 Sep 2018 10:54:08 +0200 schrieb Hans Hagen:

...

On 9/19/2018 10:24 AM, Ulrike Fischer wrote:

...

Because of a question on tex.sx I tried to use the source han sans fonts. I installed (in windows 10) the fonts from this zip-file:

https://github.com/adobe-fonts/source-han-sans/blob/release/OTF/SourceHanSan...

Trying to use them with latex/luaotfload failed with a memory exhausted error while trying to write the lua-file. In context

\starttext \font\test={name:sourcehansans} \test abc \stoptext

gave the error:

fonts > otf loading > loading 'c:/windows/fonts/SourceHanSans-Regular.otf', hash 'sourcehansans-regular' otf reader > loading of table 'vorg' skipped otf reader > invalid index in single format 1: 65353 -> 67212 (max 65535) otf reader > rule 1 in gsub lookup 's_s_5' has empty lookups fonts > otf loading > loading failed due to read error fonts > defining > forced type 'otf' of 'c:/windows/fonts/SourceHanSans-Regular' not found fonts > defining > font with asked name 'c:/windows/fonts/SourceHanSans-Regular' is not found using lookup 'name' fonts > defining > unknown font 'c:/windows/fonts/SourceHanSans-Regular', loading aborted

xelatex had no problems to use the font.

Is this an error in the font or in the fontloader?

it works ok here with luatex

but ... do you use luajittex?

No (neither with lualatex).

The context log says at the end:

mkiv lua stats > used platform: mswin, type: windows, binary subtree: texmf-mswin mkiv lua stats > used engine: luatex version 1.09 with functionality level 6930, banner: this is luatex, version 1.09.0 (tex live 2018/w32tex) mkiv lua stats > control sequences: 45351 of 65536 + 100000 mkiv lua stats > lua properties: engine: lua 5.3, used memory: 1519 MB (ctx: 1460 MB), hash type: lua, hash chars: min(32,40), symbol mask: utf (τεχ) mkiv lua stats > runtime: 39.711 seconds

The fonts *are* large, and my computer is quite old, so it could be a hardware problem, but I'm wondering a bit about the message

...

otf reader > invalid index in single format 1: 65353 -> 67212

hm checking now

-- 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://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________

Taco Hoekwater Elvenkind BV

On Wed, Sep 19, 2018 at 12:15 PM Ulrike Fischer wrote:

Am Wed, 19 Sep 2018 11:36:40 +0200 schrieb Taco Hoekwater:

...

Note, however, that the luatex process tops out at nearly 3GB RAM use while generating the cached version, which could be a problem on 32-bit operating systems.

I have a 64bit OS and 8GB RAM. According to the task manager luatex itself is 32bit.

Are you using a 64bit luatex?

Is there one for context minimals? And if yes, how could I install and activate it?

w32tex by Akira Kakuto ? -- luigi

On 9/19/2018 12:15 PM, Ulrike Fischer wrote:

Am Wed, 19 Sep 2018 11:36:40 +0200 schrieb Taco Hoekwater:

...

Note, however, that the luatex process tops out at nearly 3GB RAM use while generating the cached version, which could be a problem on 32-bit operating systems.

I have a 64bit OS and 8GB RAM. According to the task manager luatex itself is 32bit.

Are you using a 64bit luatex?

Is there one for context minimals? And if yes, how could I install and activate it? when you install the context distribution from the garden it should load 64

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Am Wed, 19 Sep 2018 13:50:37 +0200 schrieb Ulrike Fischer:

I guess I should reinstall context here, probably it is too old and never got the 64bit binaries.

I did reinstall context and now a 64bit luatex is used on my pc too and the problem is gone. I also installed a 64bit luatex for texlive and now the font can also be used with latex. The first time for me that a 64bit application makes really a difference ;-). -- Ulrike Fischer http://www.troubleshooting-tex.de/

On 9/21/2018 9:01 AM, Mojca Miklavec wrote:

On Wed, 19 Sep 2018 at 17:47, Ulrike Fischer wrote:

...

Am Wed, 19 Sep 2018 13:50:37 +0200 schrieb Ulrike Fischer:

...

I guess I should reinstall context here, probably it is too old and never got the 64bit binaries.

I did reinstall context and now a 64bit luatex is used on my pc too and the problem is gone.

I also installed a 64bit luatex for texlive and now the font can also be used with latex.

The first time for me that a 64bit application makes really a difference ;-).

I didn't look at the font itself, but if a font requires more than 3 GB of memory to be able to load it, I would suspect something suspicious (either inefficient storing of data, semi-recursive behaviour – that did happen with one basically "empty" font in the past, memory leak, ... or at least some inefficient design at some point).

these fonts are huge ... and memory usage in lua can be large as allocations doubles when more is needed, but in the end the font gets stored quite efficient in the cache, so it's a one-time memory usage

But it makes a strong argument for inclusion of 64-bit binaries into TeX Live :) we have them on the garden for ages so i see no reason for them not being in texlive

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On Wed, Sep 19, 2018 at 11:39 AM Hans Hagen wrote:

the first time caching takes some 23 sec on my (also not that new) machine but after that loading takes way less time (some .4 sec)

same results here for texlive 2018 on linux64bit Without cache system | total runtime: 23.496 seconds Withcache system | total runtime: 1.515 seconds No problem with context texlive 2018 & context with latest experimental -- luigi