On Sat, Oct 12, 2013 at 11:18:47AM +0200, Hans Hagen wrote: > 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.
The problem is that OpenType is hard, you already know that. ConTeXt will never be able to dedicate enough resources to catch up with development, so it makes much sense to reuse the efforts of other free software projects. HarfBuzz is used by much more software projects than what XeTeX was using before (Android, Mozilla, Chrome, LibreOffice, Pango, EFL, to name few), so it is here to stay. That being said, the switch in XeTeX did not affect user documents that much (apart from fixing bugs and supporting more OpenType feature, but so does ConTeXt all the time). However, I’m not proposing that LuaTeX be dependant on HarfBuzz or FreeType, but have an optional font loader and shaper that need not even be managed by LuaTeX team. Fonts change, font formats evolve, Knuth-style stability is not really achievable, unless one freezes the source code and the fonts forever, and you can do this with external libraries, too; TeX Live is self-contained, just take a snapshot and freeze it forever, and it should be buildable as long as there are C(++) compilers. There are already few parts of OpenType that I’m not able to use in my fonts for years because they break the fonts with LuaTeX horribly. I understand the priorities of the team, that is why I think that offloading font support is beneficial to everyone. > 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). I think that is small price to pay for the gains of not having to worry about every minute detail of OpenType support. Besides doing the shaping with HarfBuzz means that many of the structures exposed by the current font loader will not be even needed, which simplifies things greatly. > 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! That is nice to have indeed, but for me having a well tested and robust font loader and feature-full OpenType engine are much more important. > 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. I don’t quit get this, but I think lots of what ConTeXt does can be done with HarfBuzz or after it is done with the shaping. > If we'd have chose a shaper a few > years ago, would we switch now? And in 5 years? And in 10? Pango was using what is now called HarfBuzz continually since 2001… > 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. That is pretty much what I want, except that I want to be able to use that with ConTeXt or it will be pretty much useless for me (I still get bad dreams for having to use LaTeX to write a font manual because I can’t use XeTeX with ConTeXt and the font would often just break ConTeXt MkIV). > 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). I don’t think much of LuaTeX’s flexibility (or XeTeX’s inflexibility) is related to the OpenType layout engine used. Regards, Khaled > 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 > ___________________________________________________________________________________ ___________________________________________________________________________________ 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 ___________________________________________________________________________________
