[OpenFontLibrary] Recent non-font content on OFLB

[Christoph Schäfer]

Hi Khaled,

Am Donnerstag, 11. März 2010 06:23:51 schrieb Khaled Hosny:
> On Wed, Mar 10, 2010 at 11:38:43PM +0100, Christoph Schäfer wrote:
> > Am Mittwoch, 10. März 2010 22:56:54 schrieb Khaled Hosny:
> > > On Wed, Mar 10, 2010 at 12:51:51PM -0600, Barry Schwartz wrote:
> > > > Khaled Hosny <khaledhosny at eglug.org> skribis:
> > > > > But how OFLB is going to fix this, I don't think you are suggesting
> > > > > that we (OFLB community, whatever it means) rewrite most of free
> > > > > software text layout stack (and funny "DTP" applications) to
> > > > > support advanced typography. So, I think you mean writing smaller
> > > > > applications that are are able to really utilize our free fonts,
> > > > > but I then fail to see what is the use of such applications if can
> > > > > fit in a larger ecosystem and work flow?
> > > >
> > > > That would not be the way to go. If it is going to be done at all it
> > > > has to be by getting other projects to fix their stuff in exchange
> > > > for synergistic bundling. Right now it is as if we had a Firefox with
> > > > mostly non-functional add-on support, along with a handful of sites
> > > > to which Firefox didn't link that offered add-ons that depended on
> > > > Firefox features that always crashed.
> > >
> > > I do understand this. But upstream developers are just not interested
> > > (a patch to implement proper, TeX-like, H&J for Pango have been ignored
> > > for years, all requests and offers to help implementing OpenType
> > > support for Scribus have been ignored, etc.) and I don't see this
> > > changing.
> >
> > With all due respect: Can you substantiate this assertion? I didn't find
> > a single message from you to one of the Scribus MLs regarding the issue
> > (although I may have overlooked it).
>
> I did (I'm not sure was it on IRC or on mailing list, it was like 3
> years ago), I was even asked to provide some sort of test suit that I
> sent, but my mails went unanswered, IIRC. And after all years, the
> situation is the same; every time one asks about Arabic (or Indic, or
> even OpenType for LGC scripts), we get a "we will do it after X release"
> answer, where X kept changing.

OK, you obviously have an axe to grind, although I think this is not 
necessary. If I may ask: where did you send your test suite? 3 years ago is a 
long time.

Just to give you some background: The Scribus Team is _very_ small, which is 
why we welcome every contribution and suggestion. Since Scribus is a program 
that is expected to work on Linux, different Unix flavours, Windows, Mac OS X 
and even OS/2, it's a bit hard to use libraries that we'd have to port to 
some of these systems in addition to the Scribus code and which may or not be 
working with Qt.

More importantly, we have two font and text layout experts, the first one 
being currently unable to work on the code due to reasons I cannot describe 
without violating his privacy, the other one being swamped with his job. 
Developer #2 is nevertheless working on a complete rewrite of the text system 
that will make enhancements like the one you need easier. It's just his wont 
to drop his rewrites in one go (that's when we usually announce the risk of a 
great breakage in SVN on the ML).

That being said, I really think it would be more constructive to participate 
in a discussion with the developers instead of denigrating them on another 
ML.

Besides: If it's not a coincidence of identical names, the only proof of any 
offer to contribute from your side I could find was an application for GSoC 
2007, but for something completely unrelated to typographical improvements.


>
> Even if I didn't, it is not like we are talking about some obscure
> feature Scribus is lacking, we are talking about a DTP system that can't
> do any sort of proper text layout, no ligatures, no small caps no proper
> (i.e. that actually work) H&J, 

If I may ask: When did you try Scribus for the last time? It's true that the 
OTF "Auto" features aren't available yet (simply due to the temporary loss of 
the developer who was working on it), but the rest is there.

> I'm not even talking about the complete 
> lack of any non-LGC support, fine typographic control

What kind of "fine typographic control" are you missing exactly?

> , or even lack of 
> other fundamental features like footnotes!

Errm, footnotes is a page layout feature, quite unrelated to typography, and 
it's more or less restricted to scientific texts. Most DTP programs have no 
footnote feature at all (Adobe has added it to InDesign only recently, and 
the implementation is quite clumsy). So I guess what you want is a word 
processor+*TeX+DTP. And speaking of footnotes, we found that *TeX's footnote 
options didn't cover all use cases (unless one uses some ugly hacks or 
workarounds), so we decided to prepare the text engine for _all_ use cases. 
This is _not_ trivial, especially if you consider that Scribus cannot use any 
*TeX code directly (licensing issues, using C++ and all ...).

And another hint: Guess why Adobe, with its army of developers, is still 
selling and developing FrameMaker alongside InDesign? It seems the 
combination you'd like to have isn't that easy to create.

>
> What is the point of starting yet another useless discussion if Scribus
> team shows no interest in such fundamental features, 

1) See above.

2) Complaining in forums other than the ones that actually matter will 
certainly not help to improve anything.

> the fact that they 
> ever released such a deficient application is ridicules, even
> handicapped tools like troff does better. 
> program where you can only do ASCII art, 

OK, now I got it. Obviously you have 

1) an axe to grind (see above)

2) a hard time acknowledging that developers can't read your mind (because you 
only seem to have had a short IRC conversation 3 years ago) or ...

3) ... they may even disagree with your approach.

4) no clue about pre-press. Some of the restrictions (and the undeniable 
shortcomings) are actually based on the premise that Scribus output must not 
fail in a professional print workflow, no matter whether offset or digital.

> but it does support RGB, CMYK, 
> color profiles and importing/exporting two dozens of image file formats.

Exactly. It even supports spot colours and provides great colour management, 
isn't that cool? ;) Even better: The next iteration of Scribus will import a 
lot of proprietary vector formats (do you know the difference between a 
bitmap image and a vector drawing? If you don't, please stop ridiculing 
hard-working developers for reverse-engineering and implementing import 
filters for file formats that are more or less industry standards). This is, 
of course, irrelevant if you have no clue about page layout for printing (as 
opposed to word processing or document creation à la *TeX).

Btw, I _love_ *Tex. I wrote my PhD with LyX and later LaTeX, but it's a 
different kind of animal. The day you can show me an issue of TIME or VOGUE 
created with TeX by regular users I may concede that you have a point ;)

>
> In contrast, the archaic, +25 years old TeX is able to cope with modern
> technology, and have people who do actually care about typography. Last
> month I was able to convince ConTeXt developer to implement support for
> OpenType Optical margins (opbd) feature, though there isn't any font
> that implement it (or any other system, free or proprietary, that
> support it), but I need it for my Arabic fonts, and it take a few mail
> exchanges to get it.

Since you never seemed to try to establish a communication line with Scribus 
(again, I may be wrong, but I didn't find anything that would support your 
allegations), this seems to be a dead end.

Khaled, why don't you send an emotional (if necessary) rant to the Scribus ML 
and offer solutions if you need a DTP program that fulfills your needs? 
Ranting on another ML certainly doesn't help!

Please feel free to contact me off-list!


Cheers,

Christoph