On 10/13/2013 10:15 AM, Khaled Hosny wrote:
> On 10/12/2013 12:19 PM, Khaled Hosny wrote:
>
>> 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
>
> I bet that previous libs and whatever also have that impression ..
> I don’t think so, ICU Layout Engine was only used by Java, OpenOffice
> and XeTeX (as far as free software is concerned), and even for XeTeX
> it was not adequate and had to be patched. This is different from
> HarfBuzz, which is a mature piece of code that have been developed
> and used over a long time and is seeing a wide adoption, my
> impression is that HarfBuzz is here to stay, just like FreeType; so
> many people are investing in it.
seen next remark
well, in the end I think that open type will fade away too into
something else as its design is sort of a compromise. The dev cycles
get smaller each year, the claims for 'being the final solution' get
more, who can predict ...
I doubt that OpenType is going anywhere, not matter how bad it is, the
industry has invested so much into it and switching to any completely
new solution will be prohibitively expensive.
I'm around long enough to know that this is a dream. What makes us think
that solutions (and the political entities that harbour them) we cook up
today are the best and stay forever? I'm pretty sure that many though
that about paper books. Just look at what came up the last few hundred
years ago and faded away. Look at empires. We can only hope that content
can be transferred to new 'standards'.
It helps to watch the movie about the linotype machinery: a big
invention at that time, claimed to have transformed the world due to
more info carried around, but all hardware trashed within a few years.
So, what will happen when quantum computing combined with some AI shows
up? All our claimed perfect and persistent technologies will disappear
within a moment. So ... 'anywhere' == "today + a few years".
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.
once we have a more or less standardized lib loader (the swiglib
project) one can use such libraries, i.e. there is no need to have
something more in the luatex core; after all, it all boils down to
passing info around; anything hard plugged into to core (even
options) will be hard to fight if one wants something else
An external module is fine by me, I’m not concerned about LuaTeX itself
since even the current loader is not integrated, I’m rather concerned
about the ability to use the new loader and shaper with ConTeXt.
In principle one can plug in anything if it behaves nicely, but of
course one cannot expect existing mechanisms (we have additional
features and such) to be dropped in favor of something else without
pretty good reason.
Btw, for me (that is personal) i think that it's not bad to have an
alternative shaper like we have in context if only because a standard
(like opentype) is no standard if there is only one (to be used)
implementation.
Also, keep in mind that one can have similar arguments for all
components of luatex:
- use javascript instead of lua (if we'd started 15 years ago it would
have via perl and python and ruby so if would mean yet another change)
- use ghostscript as backend
- use graphicmagic for loading graphics
- use some html renderer (which one to choose) for rendering math and
tables
and eventually:
move on to english only so that we can also drop complex scripts and
stick to ascii latin (thinking of it: scripts and such, including math,
are the main reason that tex has survived and that only happened
because we could mess with fonts independent from already faded out
other approaches and programs ... ok, in special ways, but still the
messing around meant survival)
at that point i can look into for instance freetype and see if a
better loader can be made, who knows ... for me loading and shaping
are different things
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.
well, practice ... one also needs to freeze the operating system then
but I'm not claiming that long term stability; there was a time that
tex was a big system, but nowadays the tds tree is relatively small;
unless something magic happens, i think that at some point the
complexity of all these big things will explode (one can according
to the evangelists get a ruby on rails app up and running in minutes
... but try to update one a few years later) ... with respect to
tex: the source tree/build is not trivial (how many folks know all
ins-and-outs?) and it makes me already feel quite dependent .. it's
the instability of the whole eco system that bothers me
well, the formats don't evolve that much, at least not with respect
to what we need in tex ... most features are rather generic, but tex
user demands evolve and those will always influence matters; also,
in the (context) machinery at some point i want to play with other
approaches and then the only thing that matters is having data
available (we already have some par optimizing code in place for
instance)
(i'm more worried about inconsistencies and a mess in fonts than in
the opentype standard ... many characters / scripts / languages have
well properties, so in fact designers could do with predefined sets
of features and rules ... sort of the reverse of making shapes and
then the features: instead of for each font reinventing the wheel,
choose a set of logic, make shapes etc ... positioning is probably
most of the issue then; but that's another disucssion)
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.
break in what sense? what features (just curious) ... anyway,
The mark filtering sets we discussed few years ago, for instance; I had
to redo the whole font in a much more complex way with few more
thousands of glyphs to avoid using them so the font remains usable with
ConTeXt, and I still get crashes every now and then that I stopped
bothering with reporting them.
Well, I can't fix something if I don't know about it ... one thing I
learned the last years, is that one needs examples of usage (and I'm
pretty sure that some of the implementation of an opentype engine is not
a direct consequence if the standards but of usage).
Teaser: if another app doesn't crash, it doesn't mean that it does it
right. But its behaviour could become the standard expected. I'm not
saying that this is true in your case, but we need to keep this option
open. Also, when something is non trivial (and I've had enough
discussions to know that the spec is not always that clear) one might
wonder about the spec in the first place ... trial and error (due to
lack of fonts and examples) is part of opentype implementation
development (ok, for much other dev too).
Which reminds me: on the agenda is to have a few more fields in glyph
nodes so that we can simplify some of the code, but that's a something
we will look into end-of-year when some other backend cleanup has
happened.
I still remember a talk at bachotex where someone went through all
version of indesign pointing out in which ones ligatures did / didn't
work, workes differently. And look at opentype math ... some reverse
engineering is needed. To me opentype is not a real standard but m ore
reversed application specification where we have to look at what the
inventors do and try to adapt to that.
there's always xetex as alternative -)
Except I can’t use it :) even with MkII as there is zero support for
XeTeX’s (rudimentary) RTL model.
(unless you're referring to wanting to use the microsoft word math
renderer trickery -)
I never set math actually :) unless I’m testing a math font, but I can use
plain for that.
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.
I can imagine cases where things happen before shaping that have to
be taken into account when shaping, and also that shaping signals
things to be done later ... once we start thinking out of the box
... but, i don't see a problem in having multiple shapers (dozens)
as long as (in context) they can cooperate, be isolated, controlled,
etc. My main point is that I don't like a hard coded choice in
luatex (also performance wise). The current core components still
resemble tex.
I absolutely agree. All I wanted to know is whether ConTeXt can consider
integrating an optional different font machinery, so to not waste time
on something that will be of little use to me.
Regards,
Khaled
___________________________________________________________________________________
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
___________________________________________________________________________________
--
-----------------------------------------------------------------
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
___________________________________________________________________________________
