Are you sure you thought up something entirely new? :-)

(See Wikipedia for a short list, and the Microsoft reference at the bottom for the list as defined per 2002.)

I'm guessing here, but I don't think it's much work to add a new feature tag. The actual problem is in making OTF-enabled programs do something with text that uses the feature -- a lot of otherwise very interesting features simply don't do anything in the OTF-aware software I have. I'd love to experiment with the "random" feature ...

@ TypeSETit

As far as I know, you can compile unregistered features. You cannot activate, but you can compile them. And isn’t the syntax of all features the same? So, what do you mean with “developed”?

Alternatively you can use one of the ss-features. Because of the feature names block they are predestined for that in my opinion.

Given how many opentype feature (or even tables) that existed for years and nobody ever implemented it, are you sure a new feature is your only option?

I have done a bit of research at:
http://partners.adobe.com/public/developer/opentype
and have not found a feature that will do what I am talking about. There is a lot there, so I may have missed what I'm searching for.

Forgive me for being vague, but I'd prefer not to discuss the exact function of the feature in a public forum, but would be happy to give more details in private.

RL

TypeSETit

Is it the money or the honor, that you don’t want to discuss details in the public? In my opinion discussions about features belong to the public. Or would your feature need an extension of the OT format?

I doubt, that anybody would steal your idea, if you really have a new idea of a feature. It seems to be more than the feature.

It seems hard to imagine how you could establish a new feature without revealing it... plus, given the ingenuity of some of the people around her, there may be someone who can see a way of implementing what you want without a new feature.

I do encourage you to discuss the idea openly. There's no IP attached to OpenType Layout features, and if you were to claim IP, e.g. a patent, you'd probably guarantee that the feature would never be supported anywhere. At most, I think you risk someone telling you that the idea is stupid, and I think that unlikely.

If you're simply shy, how about if I go first? These are a couple of OTL features that have been kicking around in my head recently:

1. 'dcap' -- Drop Cap Forms
GSUB feature. Accesses variant glyphs for use as drop caps. In some fonts these might be identical to 'titl' glyphs. In some fonts they might even be floriated or otherwise decorated initials. Enumerated variants (type 3 lookups) could be linked to drop caps of different sizes, e.g. two-line caps, three-line caps, etc. Feature would interact with application drop cap functions.

2. 'rcxt' -- Required Contextual Alternates
GSUB feature. While may fonts include contextual alternate glyphs that are discretionary (typically on by default using the 'calt' feature but possible to turn off), there are some designs in which text is malformed if contextual alternates are not used. This feature would house contextual lookups that would be on by default and could not be turned off by the user. Obviously a font might contain a combination of 'rcxt' and 'calt' features. [I would have used this in the Gabriola font for MS if it has been available, and am working on another project for which it would be relevant.]

I'd love to see sort of scale parameters in OTF fonts -- you know, where a small font gets wider and thicker and a large font gets skinnier. Away with those multiple "Optical size" fonts!

It would need a sort of re-write of the basics, though, adding something akin' to Multiple Masters.

Yes, I was a bit concerned that my idea was either already available, or impossible to do, thus, a stupid suggestion. But I have since spoken to a couple of people and it sounds like the feature isn't something that's possible.

I hate getting warnings when I'm trying to do something that is somewhat unorthodox. And since I'm not a technical person, I don't know what my unorthodox steps would lead to with regard to problems.

Having said that, here is what I wanted to do. The issue is with ascenders and descenders extending past their parameters. If you want to make a font that has very long swashes that extend past the ascender and descender lines, when you generate the font, at least in FLAB, you get a warning.

My idea was to create an OPENTYPE feature that would allow you to create a glyph at half the size of the rest of the font, and then the feature would double whatever point size the user had assigned the font from within a program.

Over 20 years ago, when I first started making fonts with Fontographer, I discovered my own little trick for having characters extend past the boundaries without having them chopped off in PageMaker view. For example, if I wanted a swash letter y to extend far below the descender line, I would design it that way (ignoring the boundaries). I would then select the glyph cell from the main font window, and reduce it's size 50% (making sure that the metrics also reduced by half).

I'd then generate the font, and begin using that "y" in my work. Of course it was only half size, so whenever it appeared, I would simply double the point size. For example, I would have a formal script and the text would be set at 36 point. If the bottom line of text had a "y" that I wanted to be a bit swashy and extend past the descender line, I would simply type in that alternate "y", and then make it 72 point. VIOLA! It appeared as it should, perfectly— and EVEN if the font was a script with connectors, it lined up perfectly.

The feature would be called dubl (double character size). Or I suppose it could be called prct (for glyph at a percentage of size).

Let's say the lower case characters will have extended ascenders/descender. I thought that to program it, I would make two classes:
_________________________________________________________

[class]
dubl01: b d h j k l p q y

[class]
dubl02: b.001 d.001 h.001 j .001 k .001 l .001 p .001 q .001 y .001
_________________________________________________________

Then for the OpenType Feature, it would look something like this:
_________________________________________________________

feature dubl { # Double Size Forms
# Latin;

sub @dubl01 by @dubl02;
} dubl;
_________________________________________________________

That was my idea... and all because I hate those silly warnings.

RL

Theunis,

the full-blown Multiple Master implementation was present in the OpenType specification version 1.0, and was removed in version 1.3 (in 2001). The last version of the OpenType spec that includes the MM tables is version 1.25, and it is still available from:
http://web.archive.org/web/20010204051700/www.microsoft.com/typography/t...

I've seen a few OpenType MM fonts, and principally it would be possible to implement a typesetting engine based on the OpenType spec including these removed tables. FontLab Studio even has code to read and (I believe also) write those tables, though they are not exposed to the user, since no current application implements them.

Robert, I'm afraid your OTL 'dubl' idea won't work for a whole bunch of reasons. The notion of having half-scale glyph variants and them doubling the point size of the text setting is appears to make sense -- as you discovered when you implemented it manually in older fonts in PageMaker --, but it won't work in terms of OTL GSUB.

One problem is that OTL is applied to discrete glyph runs, and changes in point size are one of the criteria by which glyph runs are split. So as soon as you double the point size to scale up one of your half-scale variants you have lost all possibility of OTL interaction between this glyph and adjacent glyphs at the smaller point size. Basically, you'll be splitting individual words into multiple glyph runs.

Another problem is that while this may appear to work in page layout applications with absolute leading values, any application applying linespacing as a multiple of either text point size or OS/2 or hhea table vertical metrics will produce different linespacing for any line involving the double-size glyphs. MS Word documents, for example, are going to look a terrible mess with different size glyphs interspersed amid the text. Sure, you might not use such applications, but a millions of people do and you're not going to get an OTL feature approved and supported that causes that kind of problem and potential support costs for application makers.

The good news is that if you set your OS/2 vertical metrics values correctly, you don't actually need this proposed OTL feature. Clipping in TTF/OTF fonts is governed by the OS/2 table WinAscent and WinDescent values. So long as these are not smaller than your tallest glyphs, you should not experience any clipping. Most Windows applications also use these values to determine automatic line height, which means that fonts with very tall extenders will tend to have very wide linespacing in such applications, but at least they won't be clipping.

[In theory, you can control automatic linespacing independently of no-clipping zones, using the OS/2 Typo metrics and the fsSelection bit 7 setting that tells an application to use these metrics instead of the Win metrics for linespacing calculation, but in practice there isn't a lot of support for this. It is still worth doing, however, if you have a font with very large Win metrics, because the latter will otherwise also be used to scale the font sample in the Word font menu, resulting in visually very small menu entry.]

@ Robert

The FontLab warning is regarding to the UPM size, but not to the boundaries (the the font bbox). FontLab reports a wrong information. And the report should not be called warning, but information.

If you reduce the size of the glyphs, you loose precision.

I am not sure, if I understand you correctly, but it sounds like you want to catch “bugs”, that are caused by the different misinterpretations of the specifications through the developers of DTP applications by adding a feature.

As I said, I am not sure, if I understood you correctly, but I have more than doubts, that your feature would be registered, even if it would be actually technically realizable.

I hate getting warnings when I'm trying to do something that is somewhat unorthodox.

The term “unorthodox” is absolutely neutral in my understanding. I have an unorthodox but effective method for tying up my shoes. I never was warned, that it is the wrong method, but I got the info, that it is not the usual method. If it would be dangerous, I would be grateful for becoming informed, except the person, that informs me, has the unorthodox method to bring me in the danger of becoming a victim of my unorthodox method.

Thanks, Adam. That seems to confirm my idea any OpenType feature is worthless if there are no applications supporting it.

John,
instead of having a separate 'required' feature, it would be nice if lookups could be marked explicitly as required and have them applied by default, without the option of turning it off.

Hi, Paul. Yes, I've also thought that the three states of OTL — on by default and cannot be turned off (required); off by default but can be turned on (discretionary); on by default but can be turned off (standard) — could have been addressed as a flag at the lookup level, rather than requiring multiple features. But that would require a completely different feature/lookup architecture than OT provides, and its too late in the day to make a fundamental change that would be backwards compatible with existing implementations. So it will have to be new features.