On 10/12/2013 9:27 AM, Khaled Hosny wrote:
On Sat, Oct 12, 2013 at 02:19:16AM +0200, Hans Hagen wrote:
On 10/12/2013 2:15 AM, Philipp Gesang wrote:
···<date: 2013-10-12, Saturday>···<from: Hans Hagen>···
On 10/12/2013 12:48 AM, Thangalin wrote:
Hi
(Copperplate is going to be added soon.) Unfortunately, Context
Keep in mind it was only Copperplate 33 BC. Also note that I could not
find any version of Copperplate 33 BC online that had the same file
size as my corrupt version. (I was trying to find the source of the
corrupt copy.)
Most other copies, I'd imagine, are fine, so don't be too quick to blacklist it.
indeed, and when you don't notice that it's blacklisted, it can happen
that this one instance gets unnoticed
does not yet have blacklisting functionality (it’s marked as todo
in the source) so you’re going to have to filter out bad files
>from your font directories by hand.
Sounds like the real solution is to fix fontforge so that it doesn't hang.
sure, although a crash has the nice advantage of knowing that a font
(collection) is crap (which i then can blacklist permanently in my mind)
Sure, but there’s a difference between a crash and a freeze. The
latter can be quite annoying for those who work with strange
editors that run TeX somewhere in the background making it
impossible to kill the process using Ctrl-C.
it depends what causes the freeze, for instance if there is a
circular reference someplace, then that is hard to catch unless one
uses timeouts which in themselves are tricky (not much different
from browsers locking up on some javascript); keep in mind that we
load a whole font, while other applications might do a partial load
and never see the problematic data (maybe even ignore portions of
the font)
Which is something we ought to do, serializing the whole font to a lua
table is problematic in many ways (too slow, takes much memory, etc)
while SFNT fonts are designed in such a way that you can go directly to
the part you just want. And FontForge is not that robust (and it is not
a font loading library after all).
The whole font is not loaded, unless one does the to_table of the font
table, but normally it goes stepwise. Also, once the font data is at the
lua end it's fast and efficient to use it while any interfacing to a
library will be much slower (crossing the lua-c boundary) and (at least
for me a no-go given what things i hav ein mind).
I have been dreaming for a while of making an optional font loader for
LuaTeX using mature font libraries, e.g. FreeType for loading fonts,
HarfBuzz for shaping, may be FriBiDi (not a priority, BiDi in Lua is not
hard) and even FontConfig (when available) for searching system fonts.
But no much time unfortunately, and the fear that I wouldn't be able to
use it with ConTeXt is not that motivating. Someone is, however,
experimenting with such a thing:
http://www.readytext.co.uk/?p=3143
Personally I think that this will defeat the purpose we had in mind with
luatex: small basic tex kernel and everything else in extensible lua,
not too far off what classical tex had as purpose: long term stability.
We already have xetex that uses libraries as alternative.
(Although the fact that xetex changed libs is proof that libraries
introduce a dependency and possible stability factor on the long run.) I
also think that people who want to use all those libraries are better
off with other tools than tex. We already have a dependency in xpdf
which is a moving target too and has seen changes. The fontforge code
was deliberately included to be independent. Okay, we have a few
dependencies in luatex, like lfs, png, jpg, xpdf but that's somewhat
limited. In the end we hope to have the backend at least properly isolated.
One problem of moving to for instance freetype is that we then need to
get at least the same kind of data structures (ok, one could interface
compatible using lua, but then I'd end up in a rewrite again, and it
makes no sense to spend my live rewriting every few years). In the end
I'd still need to construct and cache lua tables in order to be able to
do the same (and more). A nice thing about the current fontforge libs
(which taco wants to isolate as independent lib too) is that we also
have a open source editor that has a similar structure / view on the
font. And that was a delibarate choice!
Concerning a shaper, it would demand list deconstruction and
construction, working within the constaints of the shaper that normally
operates on different data structures than node lists, where (i guess)
it becomes pretty hard then to do intermediate steps, mess around a bit,
bypass etc etc. while in luatex we have a more or less consistent view
on matters (read: lists). So, in the end one ends up with a patched
shaper to deal with some matters which then defeats the purpose. If
we'd have chose a shaper a few years ago, would we switch now? And in 5
years? And in 10?
Of course, when we have the swiglib interface ready (sometime next
year), one can always load a library and mess with it, but on purpose we
keep libraries outside the core then. So, in that case one could
serialize a node list to wherever and push back the result. Of course
that could not play well with existing (mixed) font models but that is
then up to the user.
One important aspect is that when using tex, one also wants flexibility
and control and so a font system will have hooks and such. Using a mixed
library / lua / tex approach would become pretty complex. Sure, the
current lua code is not trivial either but can probably be simplified
over time once settled down. One reason for me not to use xetex (plus
its libs) is inflexibility. If we hadn't started luatex I might as well
have opt out of tex altogether, especially because only with luatex i
can do some of our projects within acceotable bounds (dev time, speed of
machinery, flexibility).
Talking of dreams: mine is to have a real clean and independent luatex,
not dependent on large third party libraries, only lua + a few small
libs maintained as part of luatex, in a simple source tree that can be
compiled with a simple setup. I've seen too many open source projects
divert, change, abort, etc to believe in long term support (which is why
i get more and more careful in what i choose to use). Just look how
often browsers change policies, components, etc.
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
-----------------------------------------------------------------
___________________________________________________________________________________
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://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
