Talk:OpenType

Computing High‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
High	This article has been rated as High-importance on the project's importance scale.

Typography Low‑importance

	This article is within the scope of WikiProject Typography, a collaborative effort to improve the coverage of articles related to Typography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TypographyWikipedia:WikiProject TypographyTemplate:WikiProject TypographyTypography articles
Low	This article has been rated as Low-importance on the importance scale.

Tip: Anchors are case-sensitive in most browsers.

This article links to one or more target anchors that no longer exist.

[[Microsoft Word#Word 2010|Microsoft Office Word 2010]] The anchor (#Word 2010) is no longer available because it was deleted by a user before.

Please help fix the broken anchors. You can remove this template after fixing the problems. | Reporting errors

Comment

several unique options which enhance the fonts typographical abilities and fonts can have advanced typographic features, which allow proper typographic treatment of complex languages, and advanced typographic effects for simpler languages Is this an anecdote or an article with information?

"math" script tag

Section Script tag says that the math script tag has not yet been standardized. Yet the 2009 revision of the ISO spec (downloaded from the link in the references section) does mention that tag. Doesn't that mean it has been standardized?

Para 1 correction?

there are over 7,000 fonts available in OpenType format, with Adobe's library making up for about 1/3 of the total.

I believe you mean "making up about one third"--comprising--rather than "making up for..."--compensating.

I think you are correct. I deleted the extraneous word "for". In the future, you are welcome to be bold and make such changes yourself. JDLH | Talk 23:26, 10 November 2005 (UTC)[reply]

Link to www.fontshop.com - drop or keep?

On November 21, 2005, 194.208.119.18 made this change: "removed link to fontshop.com: nothing opentype-specific here, just general font-topic and custom made fonts (ad?)". The text they removed was under External Links:

FontShop — Experts in OpenType conversions and custom OpenType fonts: http://www.fontshop.com

Is this deletion appropriate, or should the link be restored?

Arguments for the deletion being appropriate:

Fontshop.com is a font vending site
this is the most commercial link of the External Links set

Arguments for restoring the link:

Fontshop.com does have a category of OpenType fonts, letting you see a wide selection of OpenType examples
- By this argument, we should also put in a link to http://www.adobe.com/type/ and other font vendors with OpenType products and information about their characteristics
this link has been in the page for a fairly long time; it was added on 2005-08-31 11:57:28 by User:Schawel
this link is definitely relevant to the page, and definitely not blatant link-farming

Your thoughts?

If there's no further comments in a week or so, I think I'll restore the link. Unfortunately, I can't get through to the person who made the change, since they didn't have a user ID. JDLH | Talk 17:37, 21 November 2005 (UTC)[reply]

The link wasn't restored, but it shouldn't be. FontShop is not among the leading makers or sellers of OpenType fonts, either in volume or involvement in the OpenType community. They were not particularly early adopters, and there is little to distinguish them from at least a dozen other font makers as far as OpenType is concerned. There are many other commercial links that would make more sense, and those links aren't here either. The FontShop people are nice folks, they make some good fonts, and I wish them well - but there's little logic to having a FontShop link here. Thomas Phinney 6:15, 2 July 2006 (UTC)

Adobe products

I am one of the senior technical support team at Monotype. Twice I have written that Adobe CS products and above are the only adobe products compatible with opentype and twice its been removed, can some one explain why this is? sailor iain 08:30, 31 July 2006 (UTC)[reply]

____

Because your statement is incorrect. InDesign, for example, supported OpenType fonts and features from its first version.

Strebe 05:08, 1 August 2006 (UTC)[reply]

____

First, if you want to know which Adobe applications are not compatible with OpenType, it's listed in Adobe's OpenType readme, here: http://store.adobe.com/type/browser/OTReadMe.html#Anchor-22064.

Besides the fact that it's wrong either way, this is a common misrepresentation, to say that an application is only "compatible with OpenType" when it takes advantage of the additional features of OpenType. There's a big difference between a font not working, and it not having automatic ligatures and easily-accessed small caps. If you want to know which Adobe applications support which OpenType layout features, see the chart on the last page of Adobe's OpenType User Guide, here: http://store.adobe.com/type/browser/pdfs/OTGuide.pdf (you'll see that the list includes InDesign 1 and 2 and Photoshop 6 and 7, all before the CS products).

Thomas Phinney 07:21, 3 August 2006 (UTC)[reply]

in my view, "OpenType support" should mean "full OpenType support". Anything else is "partial support". I am frustrated by applications touting OT support, and then failing to support the feature I happen to need. Right now, I am interested in proper diacritics handling (mark, mkmk) and vertical kerning. I don't know a single word processor who does that, even Mellel (which has above average OT support). Are there any applications that fully support the OT standard, at all? which ones? It seems incredibly annoying to have such a standard in place for 10 years(!) without a single implementation. dab (ᛏ) 07:49, 15 September 2006 (UTC)[reply]

"Flavors" of OpenType?

Can someone add some info about "flavors" of OpenType. Using Linotype FontExplorer X, when I do a get info on a typeface, some display "Opentype (PostScript flavor)". What does this mean? --24.249.108.133 16:28, 22 November 2006 (UTC)[reply]

As the article says, "An OpenType font can include either TrueType outlines or PostScript-style outlines (the latter stored in the Compact Font Format with Type 2 charstrings (CFF)." PostScript flavor probably refers to the font having PostScript-style outlines. TrueType flavor probably refers to a font having TrueType outlines. I'll revise the wording of the article to make this clearer. --Jdlh | Talk 20:13, 22 November 2006 (UTC)[reply]

The section on Mac OS X support

This section seems to me to be too general and dated.. It seems to only be talking about low level Mac OS X APIs and not the Cocoa Text System that most new applications interact with. Apple’s AAT and ATSUI are only small part of the Mac OS "X text handling classes. My experience with the Cocoa text system is that iit is far more advanced than anything else I've seen for text. I'm thinking of adding something to clarify this, but I wanted to see if the original authors are still here and can provide some clarification. Indexheavy 09:01, 1 May 2007 (UTC)[reply]

Agree with previous poster. In addition a general update according to Mac OS X 10.5 (Leopard) is needed. Mlewan (talk) 22:48, 8 December 2007 (UTC)[reply]

Note that search is not supported for intelligent font model substitution in Apple system PDF services. For instance, if the annual accounts of Apple Incorporated are composed in tabular numbers that correctly align through the column, the accounts will not be searchable after saving through Apple system PDF services. This is true whether Apple Advanced Typography or Microsoft OpenType is composed in Apple iWork or Apple TextEdit. Glyph substitution allows glyphs to be drawn even if their glyph codes are not directly depicted onto character codes in a coded character set, that is, glyph substitution protectively separates processing in the domain of character information from processing in the domain of imageable composition. In the intelligent font model of the Unicode Consortium, the CMAP Character Map transforms public and font-independent character codes to private and font-dependent glyph codes. Apple's supplements support substitution through the MORX Metamorphosis Extended tags and Microsoft's supplements support substitution through the GSUB Glyph Substitution tags. Thus reshaping for an English typographic ligature is not done by drawing in character space, but is done by drawing in glyph space such that the private glyph codes for e.g. letter f and letter t are substituted for the private glyph code for ligature ft (13 April 2010, [email protected]).

Large List

Much of the article is made up of long lists of tags. Does anyone think it would make sense to give the tags their own article? The lists make the article really long.

Besides, I feel the list of tags doesn't really fit with the article. The article is there to give people an overview of the Open Type format - the list is more specific then that. It disrupts the overview with very technical information. If we moved the lists to a new page, we could unify the topic of this article, while giving the list of tags a place where it can be more organized. Nlm1515 22:07, 8 September 2007 (UTC)[reply]

My rough guess is that the tags lists make up 1/3 of the vertical height of the article. I don't think that's excessive. One intermediate option is to add markup to put the tags lists into two columns. Now, on the other hand, I've had experience where taking a list out of the main article and making it a separate "List of" article really helped the list improve. So I won't fight against making a "List of" article. Note there are really two lists: list of layout tags in OpenType spec, and lists of tags supported and not supported by OS X. I could imagine that someday someone would want to add the list of tags supported and not supported by other text layout engines, such as those in Windows Vista, or Adobe InDesign, or FreeType. --Jdlh | Talk 22:30, 10 September 2007 (UTC)[reply]

Script tags

Are script tags compatible to ISO 15924? Christoph Päper (talk) 11:29, 19 January 2008 (UTC)[reply]

No. VasileGaburici (talk) 10:58, 22 July 2008 (UTC)[reply]

Restructuring/deletion of tags list

There were some additions of detail and some substantial restructuring on July 20, 2008 to this article. The list of OpenType feature tags was moved to a new article List_of_typographic_features, which is a list of OpenType features (names only, not tags) along with a list of AAT features. The list of OpenType features, with tags, was moved to a new article OpenType feature tag list; other editors immediately tagged this list as being inappropriate for Wikipedia per WP:NOTTEXTBOOK, and proposed moving the content to Wikibooks. I'd like to suggest that those who follow the OpenType article look at these changes and the consequences, and consider if there's a better way to restructure the article. I'm not persuaded that the restructuring was a good idea, and I'm tempted to undo it (restoring the list of tags to this article). Other opinions? --Jdlh | Talk 06:46, 21 July 2008 (UTC)[reply]

I found the gigantic lists in the middle of the article really distracting. I did not expect they'd get tagger for deletion as a separate article. I proposed some solutions on the talk page of the new list page for those that care about having this list. See Talk:OpenType_feature_tag_list. VasileGaburici (talk) 10:57, 22 July 2008 (UTC)[reply]

OpenType on Mac OS X / AAT question

I've been doing some work on the article Mapping of Unicode characters, filling in the various special-purpose characters that are integral to the modern Unicode text processing model. In doing so I created a section on the "FRACTION SLASH" character (U+2044) and was researching how rendering is supposed to be handled and how it is actually handled. I found that most fonts—even those that do a fairly decent job with single digit numerators and denominators—do not render according to Unicode expectations. Apple Chancery was the one font I found that was an exception, which nicely renders the string literal “4 221⁄225” in plain text as:

So since I found so few fonts capable of rendering this correctly I was wondering if this is a limitation of the OpentType font format when compared to the AAT font format? Or, alternatively, is this due to Mac OS X's limited support for some specialized OpenType font features where the same font on Windows would work correctly? I asked about this on the AAT talk page, though I thought some here might know the answer too. I want to be able to perhaps say something about this in the Unicode related article(s) Thanks in advance for any replies. Indexheavy (talk) 10:17, 11 February 2009 (UTC)[reply]

This is a function of the OpenType font's GPOS/GSUB tables and the order they, and the look-ups they specify, are applied. Bickham Script Pro, Adobe Caslon Pro, Chapparel Pro, for example, nicely creates the full fraction. Many OpenType fonts, on the other hand (Warnock Pro, Trajan Pro, Caflisch Script Pro), end up interpreting 221/225 as 22½25. (I tried these on InDesign, which does not use OS services for font rendering.) If you are finding the same fonts to behave differently on Windows, then it would be because the order that the look-ups were applied differed. There is some ambiguity in the OpenType specification in this matter. But I tried different fractions, ones that could not be confused with interspersed simple fractional ligatures, and still found no fractions generated. This suggests not a look-up order problem, but simply that the fonts don't include support for such fractions in their GPOS tables. I conclude from this that you're not trying the same fonts on Mac and Windows. Strebe (talk) 20:08, 11 February 2009 (UTC)[reply]

Actually I need to clarify. I didn't actually try the fonts on Windows. I was just asking whether there would be a difference since, for example, an OpenType font supporting Devanagari will not be used completely with Mac OS X's default OS text rendering (due to missing support for some OpenType features). Likewise a font that has AAT (GX) tables will exhibit features on Mac OS X that will not be apparent on Windows (since Windows and perhaps even InDesign cross-platform won't even recognize the AAT features).

However, it sounds to me from your answer that you're seeing the same types of errant rendering in fonts on Windows (such as 22½25). So I'm convinced this is likely font errors and not a limitation in OpenType itself. If Bickham Script Pro, Adobe Caslon Pro, Chapparel Pro on Windows are producing the correct rendering, then that suggests to me that OpenType (within a full OpenType text rendering environment) is capable of correctly rendering Unicode fractions correctly (in contrast to AAT/GX text rendering environment where I know the capabilities exist and all of the rendering resides in the font and not much rendering logic is required in the host rendering environment). Still this is an area beyond my expertise, so I'm still trying to make sense of it all. My tests are mostly on the default install fonts (on Mac OS X) since I don't really have any pro fonts installed. Indexheavy (talk) 21:30, 11 February 2009 (UTC)[reply]

I wouldn't call the fonts' behavior "errant" and "errors". The font designers, for whatever reason, constructed the fonts that way. How many digits are you willing to allow for fractions? The font sets the limit. It takes work to design a font to handle fractions like that, and any font has a limit to the number of digits it is willing to have participate in fraction creation. Not many people care about double-digit fractions, let alone 3-digit/3-digit.

To clarify, I did not try the fonts on Windows; I tried them on InDesign on Mac OS X. InDesign does not use the OS font facilities. Its behavior would be the same whether on Mac or Windows. For the same reason, InDesign does not recognize AAT features; they will not work on InDesign even on Macintosh. And again, for the same reason, the OS's handling of Devanagari is irrelevant to InDesign. Perhaps Mac OS X does not support Devanagari well, but I don't know and cannot comment on that. That would certainly be an implementation problem, rather than an OpenType specification deficiency.

Please note, as I mentioned, that some look-up order dependencies are not defined in the OpenType specification, and so there will be differences in rendering between font engines even if they support the same features. And yes, OpenType is perfectly capable of specifying fraction behavior. Strebe (talk) 02:54, 12 February 2009 (UTC)[reply]

I'm learning a lot from your responses, thank you. But I think we're not on the same page at all. When I was referring to AAT I meant specifically the AAT font format and related AAT font features (not merely the AAT text rendering environment if there is such a thing, I'm not sure). My original speculation is that AAT font features may be allowing font designers to design fonts for fraction handling in a way that is more sophisticated than OpenType and is not merely substituting glyphs for all the imaginable characters iterated around the fraction slash. Its clear to me that Apple Chancery is using a much more generalized mechanism that is not burdened with the number of digits supported as you suggest. Your intimation that font designers need to be allowed to decide how many digits support around a fraction slash tends to confirm that.

Mac OS X supports Devanagari just fine. However, it does it through AAT font features and not OpenType font features (Mac OS X is missing the necessary support for OpenType in this area). The advantage of the AAT font features is that it means Mac OS X basically supports any rendering without updating the underlying text system (the flip-side is that it supposedly makes font design very difficult since all the responsibilities for rendering lie with the font design and none of the particulars are in the text rendering system).

Also, yes I understand InDesign uses the same text rending cross platform, but if indeed InDesign renders those without AAT font features then it still answers the question. Since all the fonts you tested were not using AAT and perhaps not using AAT font features, then it seems that OpenType might not be limited to merely glyph substitution around a fraction slash but something more sophisticated (also like AAT). Are you finding these fonts only handle a set number of digits around the fraction slash? For Apple Chancery it seems to go above and beyond the call by supporting any number of non-whitespace characters (which is actually quite nice and maybe even easier to support). Or is it more generalized than that? The reason I call it an error or errant in any event is that these other renderings are not conforming to Unicode. I suppose if the font maker never intended to b conforming to Unicode than it is not an error. Then my criticism (and disappointment) would be why aren't more fonts conforming to Unicode? I'd love to find some documentation somewhere that described exactly what font properties are involved with achieving this result in apple chancery or any of the other fonts (I don't have access to any font editing tools). Anyway, this thread's probably getting way to long for a wikipedia talk page. Thanks for your responses. —Preceding unsigned comment added by Indexheavy (talk • contribs) 04:19, 12 February 2009 (UTC)[reply]

You wrote, "The reason I call it an error or errant in any event is that these other renderings are not conforming to Unicode." Unicode does not specify that arbitrary fractions are the font's responsibility. It gives directions for the use of code point U+2044 as the fractional character, but (a) The division of labor between font and layout engine is not specified; and (b) In any event the Unicode specification states, "If the displaying software is incapable of mapping the fraction to a unit, then it can also be displayed as a simple linear sequence as a fallback (for example, 3/4)." I do not think you have a case for "not conforming to Unicode."

Anyway, I tried some of the OpenType fonts again. There was no limit to the number of digits I could put in the fractions. I only said before that it is limited because I do not recall a GPOS look-up that is open-ended in look-ahead and look-behind. But some of them are very complicated, so I simply mis-remembered or may not have even realized the implications when I wrote code for it. I'm too tired to look it up. I have heard AAT allows for even more flexibility because of their state tables. I doubt it matters. In practical terms OpenType is extremely flexible. I have not met up with a real-world example it was unable to accommodate, but there are probably people who have. In this example, there is no need for the fractional behavior to be limited to digits at all; it could be whatever glyphs or categories of glyphs the font designer decided made sense.

It is certainly true InDesign makes no use of AAT extensions. It is also certainly true that OpenType is capable of far more sophistication than "merely substituting glyphs for all the imaginable characters iterated around the fraction slash". You might read over the specification if you intend to hold a strong opinion. That way you won't fall victim to the foibles of people like me. ;^) Strebe (talk) 08:53, 12 February 2009 (UTC)[reply]

I think you're completely misunderstanding me. I'm not taking a strong opinion against OpenType. I'm trying to ask questions about its capabilities. You implied to me that the number of digits handled was difficult for OpenTYpe. I had assumed it might be as simple as AAT, but that perhaps the OpenType features were not supported on the Mac OS X core services like the Devanagari example I gave (which is a limitation of Mac OS X and not OpenType or AAT).

As for your contention that this is not a Unicode error, the parts you quote are not convincing. Those quotations are directed at systems where the rendering cannot be achieved. And the part about the division of labor between "font and layout engine" is clearly directed at not assuming either an OpenType or an AAT style approach. However, if both AAT and OpenType based systems are capable of displaying a fraction correctly, then it is non-conforming of the font maker to not do so. So the passages you quote would support a non-OpenType and non-AAT font maker who was deploying a font in a text rendering system that simply had no such capabilities. That font maker could then turn to those sections of Unicode to claim the font was still compliant. Indexheavy (talk) 09:09, 12 February 2009 (UTC)[reply]

It did not occur to me that you might be taking a strong opinion "against" OpenType, so I'm bemused by your response. I am saying you should refer to the specifications of both AAT and OpenType if you intend to hold a strong opinions about their respective capabilities.

There is no such thing as a "Unicode-compliant" font by any recognized definition. The closest you could come is that the font contains one or more of the de facto Unicode 'cmap' tables — which says nothing whatever about whether it even contains glyphs for the Arabic digits, let alone whether the font itself makes any decisions about how they are rendered in the presence of the fraction slash character. Unicode is a character encoding specification. It happens to give instructions for how certain glyphs should be rendered in certain contexts, but it says nothing about whose job that is. You have chosen to interpret an obscure and elective layout behavior as a requirement for a font to be Unicode-compliant. I think if you go ask the Unicode Consortium, they will explain that they are not in the business of dictating conditions for Unicode compliance in fonts. They will state that there needs to be some way to map Unicode code points to glyphs from the font, and... that's about it. That could even happen external to the font by means of CMap tables, for example.

In particular, I do not understand your belief that just because a particular font format is capable of something, fonts in that format are thereby obliged to expose every functionality in order to be compliant with Unicode. By that reasoning, every font should contain 65,534 glyphs and should include all positioning and substitution combinations required for every language described by Unicode. A lot of other absurdities fall out that reasoning.

In any case, this doesn't really seem like the sort of discussion that belongs on a Wikipedia talk page. I am done. Thanks. Strebe (talk) 20:26, 12 February 2009 (UTC)[reply]

Well thanks for you complete lack of assistance. Maybe if you only want to pick a fight you should just refrain from editing. Indexheavy (talk) 00:21, 13 February 2009 (UTC)[reply]

Opentype-TT/Truetype distinction unclear here

Generally, "*.ttf" fonts that are available on the web are called "Truetype" fonts. This article is confusing for anybody wondering about the distinction between Opentype and Truetype, and in particular, the "Opentype-TT" fonts. Are "Opentype-TT" and "Truetype" fonts identical?

The following somewhat unclear sentence suggests that Opentype (and therefore Opentype-TT) have an extra feature called "smartfont options" (ill-defined in Wikipedia), implying that they would not be backward compatible with Truetype:

OpenType uses the general "sfnt" structure of a TrueType font, but it adds several smartfont options that enhance the font's typographic and language support capabilities. The glyph outline data in an OpenType font may be in one of two formats: either TrueType format outlines in a 'glyf' table...

But this says that Opentype-TT are backward compatible -- presumably with Truetype given the .TTF in brackets:

Amongst Microsoft's operating systems, OpenType-TT fonts (.TTF) are backward compatible and therefore supported by all Windows versions starting with Windows 3.1.

--Farry (talk) 10:11, 10 June 2009 (UTC)[reply]

The distinction is unclear because, well, the distinction is unclear. If the OpenType font carries a 'glyf' table, along with the other tables that are mandatory in the presence of a 'glyf' table, then the OpenType font is a superset of a TrueType font and likely would function well even in font systems that do not process any of OpenType's Advanced Typographic Tables present in the font. (Kerning may be problematic, though, since most OpenType fonts elect to define their kerning in OpenType's 'GPOS' table rather than TrueType's 'kern' table. Some OpenType fonts carry both tables.) If instead of a 'glyf' table the font carries a 'CFF ' table, then the OpenType font is not TrueType. Theoretically the font could carry both 'glyf' and 'CFF ' tables, but the OpenType specification recommends against this.

In summary, an OpenType font MAY be backward-compatible with TrueType, or it may not, and this compatibility is in degrees, not incisive. The verbiage you quote from the article refers to the specification, not any given OpenType font, when it says things like OpenType... adds several smartfont structures... The "smartfont" tables are all optional. Indeed, that is why the distinction between OpenType and TrueType is blurry: all of the OpenType-specific tables are optional. Strebe (talk) 18:17, 10 June 2009 (UTC)[reply]

Well put, old chum. Though I would say that an OpenType TT font is pretty much always backwards compatible with TrueType. Maybe the kerning won't be recognized, but the font still works.... Thomas Phinney (talk) 04:06, 11 June 2009 (UTC)[reply]

OpenType mimetype?

Does OpenType have a specific mimetype? I haven't found a particular answer by searching the net. If there is one, and someone knows it, please add the info to the article. Quillaja (talk) 11:58, 9 October 2009 (UTC)[reply]

Support on Classic Mac OS?

Does any version of Mac OS 9.2.2 or older support OpenType? —Preceding unsigned comment added by 66.232.94.33 (talk) 09:53, 11 March 2010 (UTC)[reply]

No--DieBuche (talk) 10:08, 14 March 2012 (UTC)[reply]

Lackluster Linux support (Openoffice, Scribus, Mozilla et c.)

Sorry if I'm ranting, but most of the open source applications, under linux, that the article claim to have Opentype support just don't support it usefully, or haven't supported it for as a long period as the article (and software developers) claim (which means that the older versions used in most linux distros don't).

I use Ubuntu 10.10 and to many essential Opentype features are amiss in to many applications. Basic features like kerning is missing in Openoffice (and Scribus, until Ubuntu 10.4 or something, it seems to work now, but that means it doesn't work in any of the LTS releases), which make documents using most OT-fonts look butt ugly (kerning works in the Windows versions of OpenOffice since many years) [I have turned on kerning in the Openoffice preferences, it is really not working]. The applications don't understand the proper tables for kerning in Openfont. Sometimes you can hack a font to work by adding old style, deprecated, TTF tables to it, but such a font confuses a lot of other applications, especially in Windows and OS X (at least until a few years ago, you could make both OS crash spectaculary with such a font). Support for many tables in CFF fonts is also missing, or is very buggy.

Applications native to linux (not Openoffice and Scribus, they may have started as native Linux applications, but are now multiplatform and Windows seem to be the preferred developer platform), have since a couple of years excellent Opentype support, as they use native standard libraries directly and not some cross-platform hack. So, Opentype kerning and CFF fonts work excellent with almost every simple text editor, just not with the most popular group of word processors used in Linux systems (OpenOffice and relatives), if you use the Firefox version that come with most Linux distributions, you are also out of luck. Since FreeType nowadays render TTF fonts using the hinting instructions within the font and that usually gives uglier shapes(*) then the previous work-around code to avoid (now expired) Apple patents, now Opentype CFF-fonts (as well as PS-fonts) usually look prettier then Opentype TTF-fonts when rendered by FreeType (and of course, it looks prettier then any font rendering in Windows too).

(*) Microsoft is the only large source of fonts that have hinting instructions better (for most computer screens), then Freetypes hack-around auto-kerning, that I know of, but the licenses for those fonts don't allow installation on other systems then MS Windows. A small number of fonts where TTF hints are generated automatically by FontForge, where the Fontforge hints is made correct (made manually, similar to Postscript hints) also have good TTF hint instruction, but only if they don't have a to different look (from how the glyphs looks in most fonts), and are properly hinted by the font creator (there are subtle differences on how to do this, from Postscript hinting best practices, so most font maker don't know how to do handle Fontforges generationed TTF hinting instructions well). — Preceding unsigned comment added by Se mj (talk • contribs) 14:44, 25 October 2011 (UTC)[reply]

The usual solution would be to fix the article. Please fix it! Strebe (talk) 18:36, 25 October 2011 (UTC)[reply]

Does the OpenType font format have support for hinting like TrueType does?

It doesn't seem to; Adobe's new Source Code Pro fonts look visibly different on my Win7 Pro computer on both my LCD monitors Both monitors are running at their full, native resolution and one is connected via DVI and the other via 15 pin "VGA". 12.202.74.87 (talk) 18:34, 13 February 2013 (UTC)[reply]

Whether a font gets hinted is up to the font developer. Both TrueType and CFF flavors of OpenType support hinting, though the mechanisms are quite different. Why would you suppose the fonts would look the same with hinting? Most likely you are seeing sub-pixel rendering on the digital connection and not on the analogue. Strebe (talk) 21:20, 13 February 2013 (UTC)[reply]

I expected the 2 file formats of the same professionally deveoloped font to either look identical or for the newer format to look slightly better, but neither was the case. I should take a screenshot and post it somewhere for illustration. And you misunderstood me; I was trying to say that the results were the same on both my analog-connected monitor and my digitally-connected monitor.

12.202.74.87 (talk) 16:20, 16 February 2013 (UTC) — Preceding unsigned comment added by 75.136.109.74 (talk) [reply]

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on OpenType. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive https://web.archive.org/20061118080709/http://www.suitcasetype.com/images/font/dederon%20Serif%20Std%20OT/01_Dederon_Serif_Std_OT.pdf to http://www.suitcasetype.com/images/font/dederon%20Serif%20Std%20OT/01_Dederon_Serif_Std_OT.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 04:56, 17 October 2015 (UTC)[reply]

List of Mathematical OpenType Typefaces

There exists at least one new mathematical OpenType typeface: https://github.com/khaledhosny/libertinus Simon.schaelli (talk) 11:09, 20 October 2016 (UTC)[reply]

Update to describe OT Font Variation

Recently I have notices OpenType specification introduced font variation techonology when I seen from this article, but I still have no idea how to describe even if I saw the who specification. Who can do it? -- Great Brightstar (talk) 16:53, 4 November 2016 (UTC)[reply]

I added a section on this within the History section. (This may eventually need to be a topic on its own.) Pconstable (talk) 21:21, 22 April 2017 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on OpenType. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20140710201619/http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ to http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:07, 22 March 2017 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on OpenType. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:40, 30 March 2017 (UTC)[reply]

Digital typography

There is a discussion at Talk:Typography#"Digital typography" that may interest editors. The present redirect target of Digital typography is being debated. --John Maynard Friedman (talk) 12:52, 24 March 2021 (UTC)[reply]

MATH table and variations

@Pconstable: This insertion is not evidently supported by the citation. Please clarify or remove. Strebe (talk) 18:47, 13 December 2021 (UTC)[reply]

@Strebe: Revised. Pconstable (talk) 17:18, 14 December 2021 (UTC)[reply]

Request for non-technical information

I have a request or suggestion. This article is technically excellent, but I'd be interested in a bit more NON-technical information. I have questions like: How widely-used is Open Type ... is it now a universal de facto standard? What is its "market share" among competing technologies? Are there other, rival technologies that have strengths that make them better choices for particular applications? Who maintains the specification? is there a consortium? etc. etc. Thanks. Stephen.R.Ferg (talk) 19:10, 18 July 2023 (UTC)[reply]