Always great to hear things being done about improving text rendering.

It would be even greater if the smallcaps feature could be used to access the smallcaps which are sometimes present in the fonts themselves through opentype features

Ben

I take it that these changes are in the way Qt does text rendering, and that Qt4.4 won’t read or write ODF on its own?

ODF writing (at least at some very high level) would be a very nice feature for a future version of Qt. In terms of high level, less “ODF as a QPaintEngine backend” and more “output this text using this style”. There is a Perl module that has some interesting ideas (http://search.cpan.org/dist/OpenOffice-OODoc/OODoc/Intro.pod), although I’d much rather be doing it in Qt

Hy.

About all these spaces : It sounds good already, but the thing in wich I would be more interested would be paragraphs skiping spaces.
I mean, anyone who has used LaTeX has probaly fallen in love with it : Elastics spaces. To be able to just say ‘ put between 16pt and 80pt, with a default of 18pt between every paragraph’ and then, you will never have a paragraph beeing cut by a page switch ( or it’s a very very long one ), it’s just such a time saver !

And an other killer feature is the floating box thing. At first, it made me cry to not have my graphics where I asked them to be, but after I understood the logic ( and that there was the choice to not use float to put an image ) I fell in love with that too.

The last thing I love in latex is the task oriented thing. ie: tell you whant to write an abstract, do not tell you whant to start on the right page, centering the text verticaly at the 2/3rd of the page, and reduce margins. No, just tell : begin the abstract here, and end it here’. It is realy confortable.

When, in 2 months, Kword (and ODF as a consequence, since KOffice team will put it in the 1.2 version of ODF for sure) support these 3 very basics features, I may consider to switch back from LaTeX

Print quality text is a lot more than kerning and tracking, though control over those in the low level text engine is likely to be handy. As one person has indirectly pointed out, most of it is really in the dynamic layout algorithms used by the app to get the text to look good. They adjust the kerning, tracking, hyphenation, etc to try to get an even text density, neat hyphenation, etc. It’s most noticeable in justified text, and especially force justified text where the whole paragraph must be adjusted so that the last line is the same density and has enough words on it to look OK.

A lot of it also comes down to details of typesetting like support for pair kerning and the use of automatic pair kerning tables in modern (OpenType / OTF) fonts. Pair kerning really helps headlines etc look good by ensuring that spacing is consistent between characters even when they have parallel diagonals (think AW vs ll vs JL - note the wider spacing in AW?) .

Good automatic typesetting also relies on high-quality controllable widow and orphan elimination (no “dangling words” off the end of a page/frame or at the start of one) through text spacing adjustment or breaking, etc. ODF actually supports attributes for widow and orphan control, so that’s another thing KOffice could potentially handle. Qt probably can’t help there, though, unless KOffice is using it for text layout - which seems unlikely.

The text layout stuff is something an app can implement on top of Qt . Built-in support for kerning and tracking will help apps do that more easily. If you were able to add pair kerning support OpenType, that’d be a real benefit. If I was to really start dreaming I’d ask about OpenType old-style numerals and enhanced support for ligatures.

It’s worth noting that even some DTP apps don’t do much in the way of automatic text handling. QuarkXPress, for example, and the current generation of Scribus, largely leave tracking, kerning, etc to the user. That has its advantages, but LaTeX and InDesign both take a smarter approach where the low level text parameters are automatically adjusted to improve the look of a paragraph, and that does tend to make things both quicker and nicer. Scribus is creeping in that direction now.

If you’re really interested in having a text engine that’s useful for good looking typesetting and DTP, drop in on #scribus on freenode or send some mail to the Scribus mailing list at http://nashi.altmuehlnet.de/mailman/listinfo/scribus (subscription required to post). There are some seriously expert DTP/layout people who’ll be able to explain better and point out other things you’d need.

I’d like to expand on Ben’s question: is Qt using OTF features for this? After all Qt is using the Harfbuzz library now, so those features should be accessible.
AFAIK OpenType supports several capitalization modes beside SmallCaps (also note that SmallCap characters are *not* just scaled down version of capital letters. That’s just a poor replacement used by many applications).

About letter/word spacing: is this fixed or is it elastic to support justification?

@kollum:
You have to distinguish toolkit features from application and document format features. Elastic spaces should be implemented on the application level. Same for floating pictures. Most textsetting application are too different to allow that to be implemented as a common feature in the toolkit. Especially web rendering and DTP have totally different needs.

Also note that the LaTeX format is layout-stable: all LaTeX (and TeX) processors are required to produce identical layouts even on different machines and different output formats. AFAIK the Opendocument format is a far cry from providing layout stability (if it’s even wanted). Scribus OTOH tries very hard to preserve layout stability even between different versions of Scribus.

@Craig Ringer:
I’m pretty sure that all current toolkits support pair kerning for OTF, TTF and Postscript fonts - it’s implemented in Freetype. The problem with headlines is that kerning tables for body text dont work so well with headings, the user has to manually adjust the kerningto get a pleasing layout.

All-in-all, it’s nice to hear about progress on the Qt text / Kword / ODF front.

Cheers,
/Andreas

Will the “make all letters be displayed in lower case” be able to make a 1:1 roundtrip? That means, once I did apply the lower-casing to a full text, will I be able to restore the original capitalization in one click (not using “revert last step”)?

This is all good, and I’m very happy Qt will have better text layout handling.
But (you knew a but was coming, right? Qt still has issues with font selection: many fonts cannot be handled by the Qt font requester (and the Qt font matching, I suppose) which makes many fonts unavailable to applications to begin with.

Particularly, compressed and expanded fonts are completely ignored (try finding Dejavu sans condensed with the Qt dialog).

I am pleased that Smallcaps are going to be supported in 4.4, we already implement that as a font property within LyX (www.lyx.org). As we do the transformation at painting time there is no change of contents either for us. Unfortunately it appears that we won’t use 4.4 soon so we have to stay with our own made solution.

@kollum: you should try LyX. It’s a word processor that recognizes that nothing can beat LateX at typesetting and use just that. Be warned though that this is not exactly a WYSIWIG processor but, if I read well your wishes for KOffice, you’ll certainly be please.

@Thomas sorry if advertise a bit LyX. This is not against KWord, those apps have simply two different purposes (LyX is more like a semantical word processor). But as we use Qt4, I thought my comment is fair