As far as I know, OpenOffice doesn't support OpenType features, and the newest version of Word does support them to some extent. Is that the type of font usage problem you're wondering about?

No, Scott, the problem is MS Office still uses the letter 'k'.

That could be fiksed for OpenOffice since it is open source.

Yup, OpenOffice is fairly awful for typography. Bad OpenType support, no ligatures, no true small caps... and the developers are quite snarky about implementing what would be a fairly straightforward feature.

*shrugs* It's just a small matter of programming, after all.

Supporting OpenType features may require a lot of programming, and, of course, since it's open source, it's not as if money coming in supports it.

But if OpenType support is not trivial - so that even, say, WordPad would fully support all OpenType features - then it may be reasonably asked whether the features in OpenType are really useful to people. If a font can "do fancy things", then it ought to be possible to make it do those things everywhere the font is used.

Which means that the mechanism currently used to get at things like variant characters, small caps, and so on and so forth, is deeply flawed.

The "right" way for a font to behave on a computer, "of course" (and I realize what I'm proposing won't happen, since it's wildly impractical for many reasons) is for it to be simple and intuitive to control all its features, i.e. requesting a long s, disabling ligatures, and so on...

when you're generating your text this way


      WRITE (6,11)
   11 FORMAT (11H Some text.)


Maybe like this:


      WRITE (6,33)
      WRITE (6,11)
      WRITE (6,44)
      WRITE (6,22)
   33 FORMAT (51H*                                                 =)
   11 FORMAT (53HA word like official is printed with the ligature ffi)
   44 FORMAT (18H*                         -)
   22 FORMAT (20H representing the letters ffi.)
C 3456789 123456789 123456789 123456789 123456789 123456789 123456789 12


assuming that * as a printer control character indicates a line containing font behavior characters, and in such a line, = means "force ligature" and - means "prohibit ligature".

I'm sure you lot can infer what I mean with "a small matter of programming".

I fail to see how doing OpenType small caps (which is just a matter of redirecting a lookup table, right?) can be more difficult to program than the fake small caps they have now. :)

"Redirecting"? Nothing to re-direct, really.

Fake Small Caps: make all lowercase character caps and decrease font size by 80%.

Opentype Small Caps:
* Parse entire Opentype font
* Look up current script
* Look up current language in current script list
* Look up 'smcp' feature in current language list
* For each character
o Check if it has a GSUB entry
o If so, do GSUB lookup for this character
- Take care to handle each Lookup Type correctly (there are eight of 'em)
o Display the glyph

'Trying to explain the one font's problem at Open Office wordprocessor thoroughly would require a font designer experience. Nonetheless I will try and hope it is comprehensible:

Layout at existing document (ODF) on OpenOffice - The document is stored on the PC, when I reopened it after a while, a text block was mostly invisible. After changing font size other than 11 to 11.6 it became visible or when font was changed. When I put 11.7 as font size, the wordprocessor jumped to 11.6 and was visible.

Layout on PDF on OpenOffice - After a document is converted to PDF some very few documents became semi-garbled.

Layout at ODF on OpenOffice - Some very few documents are not able to accept a preferred layout again - line / words jump (could be due to header/footer or mix with another font?)

The font is not available in smaller sizes up to 9. When font is put as 9, the text area frame becomes larger, shifting the total document area.

Is it possible to rectify these problems if they are easy to investigate and correct them.'

Plus, break compatibility with existing documents containing fake small caps.

Small caps is a tricky one, especially in a word processor. Fake small caps "work" everywhere, true small caps... not so much. What do you do? Provide two options? What happens when someone switches fonts with true/fake small caps applied. Seems to be more of a user experience problem than a technical problem.

What happens when someone switches fonts with true/fake small caps applied. Seems to be more of a user experience problem than a technical problem.

I don't see the problem at all. Small-caps aren't hardcoded into the document, they are stored as an argument of the respective style tag in the ODT's XML files (fo:font-variant="small-caps" in OO; I would imagine Word handles it simliarly). If the font provides real small caps, real small caps are displayed in the software. If it doesn't, scaled-down caps are displayed in their place.

If users are stupid enough to hard-format small caps themselves, they won't be affected at all.* Or am I missing something?

*I admit I have a hard time not ranting about the fact that word processors allow people to hard-format stuff at all ...

My switching concern was related to people being able to choose between true and fake small caps...

variant="small-caps-true"

variant="small-caps-fake"

Oh, I get it then. But why would anyone want small-caps-fake? :)

But why would anyone want small-caps-fake?

Because they’re customisable (the fake small caps, that is) choosing, for example, the % of caps height (not that I condone the practice ;-)
In fact, in this forum someone once argued that in order to offer a complete solution, a font need to offer no less than three different sets of small caps!

Good lord, I just want to be able to emphasise keywords in bog-standard Adobe Caslon without having to use butt-ugly bold. Is that too much to ask? ;)

no less than three different sets of small caps!

Alright, you win :-)

OpenOffice's main font problem is that it can't use OT features. OTF fonts weren't even supported at all until 3.0 and couldn't be printed or used in PDF export until 3.3, when they finally got support, but only for basic Type 1-level functionality.

Abiword, IBM Lotus Symphony, LibreOffice, KWord, StarOffice and others here http://en.wikipedia.org/wiki/Comparison_of_word_processors any good for font usage or they have problems?

OpenOffice does support OpenType, for years now, but only for CTL scripts like Arabic or Indic (using ICU or Uniscribe based on platform it runs on).

Symphony is based on the OO 1.x codebase, so it's a wash. LibreOffice is still basically identical to OO, so it's identically useless (no ligatures, no small caps, no alternates, etc) and StarOffice is just OpenOffice with some extra import/export filters licensed from a commercial vendor.

I don't regularly use the software, but it appears that Abiword automatically implements standard ligatures on some typefaces, but I don't see any means to turn that on or off, and I don't see any other more advanced typographic controls. I don't know if that's an Abiword feature per se or a feature of the underlying libraries it uses on Linux.

st

Abiword is using Pango for text layout and the later will always apply default features based on current script with no user control over it.

Ah, if only Pandora's box of WYSIWYG word processing had never been opened ... :)

I prefer LyX because it's free and support all word processor characteristics. I have it on Ubuntu 10.10.