Lots of goodness has been happening with the Open Document Format. Well, not the format itself, that has been an ISO standard for some time and that kind of implies it gets a bit boring. Fileformats being boring is, much like in governments, a good thing. Boring means stable. And we need a stable Foundation. (bonus points to the people that got the reference 
)
Like South Africa Adopts ODF, German Foreign Office comes out in favor of ODF and there are various articles going over how Holland and Belgium are steadilly switching governments but also schools over to ODF.
More close to home; my favorite OpenDocument Format implementation KOffice is based on Qt and version two will be released after Qt4.4 is out as 4.4 is going to bring a lot of improvements for it. I’m working through some of the features that we see in ODF which are pretty advanced nice little things. As you may be aware, ODF has a very wide ranging featureset. Advanced DTP like features is not something you might suspect, but its there. This is stuff I’m currently working on.
Qt4.4 will have a new “Letter Spacing” feature. Which is described in the API docs like; Letter spacing changes the default spacing between individual letters in the font. The spacing between the letters can be made smaller as well as larger.
In typesetting letter spacing is a much used feature to manipulate a text layout. This is now available for all Qt users.
Another feature is wordspacing. Which is similar to letter spacing, except it only affects the space between words.
Finally I introduced various capitalization modes for text. A text can be turned into all-caps or all-lowercase text by just changing a font-property. The neat effect is that you don’t have to actually change the text to get all characters to appear in uppercase or lowercase.
A special capitalization mode is “SmallCaps”. Smallcaps is a typigraphical technique used to put more emphesis on a piece of text without making it look like its screaming.
btw, if any of these features sound familiar from the css spec; thats entirely possible since ODF just mirrors a lot of the CSS features. No point in re-inventing the wheel, right? Naturally in ODF they are made with print-quality text in mind. Qt4.4 will support both without problems.
Possibly related posts:
9 comments
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”)?
@Brad
No, Qt doesn’t do ODF writing/reading. The plan for KOffice is to create such a library with the LGPL license so people can use that in either open source or commercial offerings. So I don’t think that Qt should compete with that
@kollum The best way to make sure a feature is going to be in KOffice is to report a wishlist on http://bugs.kde.org I don’t fully understand the feature you are talking about, so some links to docs will help.
@Craig Better justification is something that we can do after we cover such basics. We have come a long way already, but I agree it can always get better.
Kerning and tracking are already in Qt and KOffice builds on top of Qt text engine so it automatically benefits from it. widow/orphan stuff is on the KWord TODO, but probably won’t make it for 2.0 (help is welcome!)
@ Repre
In short; yes. The capitalization mode doesn’t change the underlying document at all. So setting a piece of text to AllUppercase and later setting it to MixedCase will restore your text as you expect.
This is all good, and I’m very happy Qt will have better text layout handling.
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.
But (you knew a but was coming, right?
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
Comments on this entry are closed.