[OpenFontLibrary] Recent non-font content on OFLB

[Khaled Hosny]

On Thu, Mar 11, 2010 at 08:12:31AM +0100, Christoph Schäfer wrote:
> 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!

To make it short as it is going really off-topic, and sorry I can't
comment on each point.

I realised earlier that Scribus is not the tool I'm looking for; when I
typeset text, text is my highest priority, but it is not the case with
Scribus. Life is too short, and I don't have time to argue with the
developers of every tool that I want to use, so I've to choose the
closest to my needs. I might not have any clue about printing, but I got
every thing I needed for my book (including spot colors and
overprinting) depending solely on TeX and the book have been printed and
distributed (it is not really my book, it was a collective work released
and CC but I don't want to advertise it here).

Noting is perfect, and TeX is certainly isn't, but a 90% working
solution is better than 0% one.

"Denigrating" wasn't in any way my intention, it was a "funny" remark
showing how disappointed am I with all FOSS text layout stack and
Scribus in particular. I'm not asking anyone to do anything for me, I
already invested my time in TeX and unlikely to change, so even if
Scribus magically became a usable tool for my need, I'm not going to use
it, though I'll be happy that I can point people to it.

Regards,
 Khaled

-- 
 Khaled Hosny
 Arabic localiser and member of Arabeyes.org team
 Free font developer