Conveniently you've chosen to mangle the name of the font. If you'd used its correct name "Nirmala UI" readers may have understood that the font was designed with the limitations of UI use, ie. having to work at 9pt (at 96dpi) on the same metrics as other UI fonts in Windows, and was designed with those limitations in mind. It's not a document font. But hey I'm not letting the trolls sour my day! happy Sunday everyone! :-)

To the best of my knowledge, being a UI font or not doesn't justify dropping off one stem, a confusing design style, not applying optical corrections and poor design quality. I haven't been to Reading, but I have designed 30 Malayalam fonts for print as well as UI and know that these are the basic prerequisites for any font. Can n't we expect the same standards and care that is applied for Roman fonts (UI or not) to other scripts? Or should we be happy with the breadcrumbs being thrown in our direction with every OS update? The crucial question whether anybody who knew the language was consulted is actually being evaded conveniently. May be you do not think that is important.
Sorry to have spoiled your Sunday, but I need to point out such careless designs as they spoil all our days!

The missing stem is a bug that has already been fixed.

As Si has pointed out, these are fonts that were designed to solve some very awkward technical problems inherited from the UI metrics restrictions. These account for the very particular solutions applied in the Nirmala UI fonts, which we wouldn't dream of applying if it were not for those restrictions. We 'invented a clumsy way to handle descender portions' because otherwise the below letters in conjuncts would have been clipped and unreadable. I'm sorry the results distress you, but they are far from careless and certainly not 'mindless'. A lot of thought went into making a legible design for small sizes that we could given the restrictions of the UI environment. All of which you might have known if you had bothered to make polite inquiries about the project before being so rude in a public forum.

And yes, we are working with a Malayalam language expert to resolve additional issues with the fonts, and I am currently testing entirely new and more efficient approaches to some of the OpenType layout issues.

Since it was Microsoft designing the font, if the restrictions of the user interface metrics interfered with properly handling the Malayalam script, they could simply have rewritten the appropriate part of Windows to remove those restrictions.

Now, I realize that if that would be an expensive development effort, the size of the market would not be adequate to pay for it.

But I am puzzled for one reason: in Windows, one can select arbitrary TrueType fonts to use for different elements of the user interface. If those fonts had to be special 'user interface' fonts, one would expect that the choices offered to the user would be very limited.

Thanks John for your clarifications and accepting one mistake I had pointed out. I was not being rude, but offended by the carelessness. But if I sounded rude, my apologies. Imagine if you release a Roman font (UI or not) with a missing stem for 'm', wouldn't typographers in that script be offended, insulted and certainly not amused? The 'm' with the missing stem could even be read as 'n'.

I believe languages and scripts are sensitive topics and need to be addressed carefully. Especially in India where the alphabet is often iconised and idolised. One my teachers recently pointed out a Sanskrit saying 'Na vidya mathrukapara' which roughly means 'There is no knowledge beyond the alphabet'.

Regarding Nirmala being meant only for UI, that may not be the case. Being the only Malayalam font being shipped with the OS (I am not sure if Kartika is also shipped with Windows 8), it is likely to be used for anything and everything, since there is no way to stop people from using it. Many people may use it, read it and believe it to be correct. I have seen many using Verdana and Georgia in print though they were designed for UI.

>But I am puzzled for one reason: in Windows, one can select arbitrary TrueType fonts to use for different elements of the user interface. If those fonts had to be special 'user interface' fonts, one would expect that the choices offered to the user would be very limited.

This is true for the original classic shell where dialogs would sometimes change height based on the UI font (often with poor results), but not the new Windows UI which uses a typographic grid, and where the fonts need to be on the same vertical metrics to work properly, coupled with the 9pt (at 96ppi) minimal size this led to compromises for a variety of languages. As resolutions increase we can hopefully move beyond this in the future.

>But if I sounded rude, my apologies.

Apology accepted.

>Regarding Nirmala being meant only for UI, that may not be the case.

Perhaps you could try Windows 8 and the Windows 8.1 Preview and see for yourself.

And I'm always happy to accept bug reports directly.

Cheers, Si

Hashim: Regarding Nirmala being meant only for UI, that may not be the case. Being the only Malayalam font being shipped with the OS (I am not sure if Kartika is also shipped with Windows 8), it is likely to be used for anything and everything, since there is no way to stop people from using it.

Alas, this is the case. If I had it my way, UI fonts would not be enumerated in the system Fonts folder, and would be hidden from users, appearing only in the UI environments for which they were intended. There are simply too many restrictive factors affecting that environment to make a typographically sensitive solution for all writing systems. It is a serious problem that, eventually, can only be addressed by re-designing the user interface to be more dynamic, expanding to fit the natural proportions of all the world's writing systems and not only those that are close to the Latin script. In the meantime, we are forced to make UI fonts with numerous compromises and even novelties in order to make scripts as legible as possible within the technical constraints.

I share your frustration with the poor quality of most of the Indian fonts available, and the very limited number of fonts at all for some scripts. It would be great to have more and better fonts intended for document creation and online reading, with appropriate metrics to allow the scripts enough vertical space to assume their normal written and typographic proportions.

_____

John Q.: Since it was Microsoft designing the font, if the restrictions of the user interface metrics interfered with properly handling the Malayalam script, they could simply have rewritten the appropriate part of Windows to remove those restrictions.

That is a huge supposition. There is nothing simple about rewriting the entire Windows user interface design, especially not in a way that would make it truly adaptable and dynamic.

The fixed restrictions of the UI metrics was the primary, non-negotiable term in the Nirmala UI design brief: whatever we did had to fit within the vertical metrics of the Segoe UI and other UI fonts. The core target size for UI use, despite the increase in screen resolutions on many Win8 devices, is still 9pt at 96ppi, i.e. 12 ppem, with some Office UI items displaying at 8pt (with further restrictions on ppi height through VDMX adjustments at some sizes). At 12 ppem, we have exactly 3 pixels below the baseline before we hit the OS/2 WinDescent limit, beyond which glyphs will be clipped. Many of the Indian writing systems make significant use of the space below the baseline, so we had to employ a number of strategies to squeeze subjoined letters and other descending shapes into the UI metrics. The results are not all pleasant, and some contravene the norms of these writing systems, achieving only a legible decipherability, rather than true readability.

Again, the long term solution has to involve a redesign of the UI to make it properly adaptable to different scripts and languages. At that point, Nirmala UI will be obsolete; for now, it is an improvement over the hodge-podge of different fonts used previously for Indian localisations, is consistent with Segoe UI and other Windows UI elements, and is so within some terrible technical constraints.

All that boils down to one question:
Shouldn't people who know the language and the script be involved in designing its typefaces—print or UI, I still don't appreciate the double standards—for it so that informed decisions are arrived at and blunders (bugs would be too polite a term) do not happen again and again along with the invention of clumsy solutions? Should people who do not read, write or speak the language pose as experts and impose designs on those who read, write and speak the language? Shouldn't the people who use it have a say in its design? India has design schools and competent type designers in every script. Shouldn't they also be involved rather than people who are seeing these scripts for the first time in their life. Or am I asking for too much?

If Kartika was crudely designed, Nirmala was born handicapped and no fix may undo the damage done. I shudder the day when I see books, notices and ads printed with the disformed letter which is frequently used and the clumsy conjuncts with the wavering baselines. Some people may even think that this is the way the letter and the script should look like. I have heard of cars being recalled en masse to fix technical issues discovered later. Is there such a possibility in software releases?

Personally, I (and probably anybody who loves their mother tongue) would refuse to use the software until the blunder is corrected.

@hashimpm – Show them how to do it, then.

Show them how to do it, then.
>>Would love to. I had already sent some suggestions to John (copy attached), though it is too late.

The damage done to the language cannot be undone until the software is recalled.

I fail to understand why type design is still considered 'white man's burden': to uplift and civilise others. Even when there are capable people in those languages, the decision makers prefer people who do not speak, write, read or understand the language to those who do. And the damage done is for all to see. When you point out the blunders, you are asked to be polite. You make blunders and I have to apologetic? Type colonialism?

Nirmala has many others scripts in it other than Malayalam, I just hope they are not as bad.

Fact: You are more likely to get the result you want by being polite than by starting a war.

Fact: Software is never recalled, just superseded. Old versions tend to linger on until the users actually install new versions. This is especially the case with fonts. They are given a very low priority in auto-updates as Si and John have recounted before. so users must themselves look for updates.

> Software is never recalled, just superseded

Yep, very few products of any kind are ever recalled. Recalls are generally for defects that are safety hazards.

Culture aside...imagining the main stem thickness of this design with only one pixel to show it, the suggested changes are utterly insignificant at UI resolutions, (unless one is charging per hint).

1. You are more likely to get the result you want by being polite than by starting a war.
>> No intention to start any war. I had mentioned many of the mistakes in the previous Malayalam font Kartika years back (http://typophile.com/node/51298), but from the repeating the mistakes and creating more, it shows how futile the attempt was. I still don't know how pointing out mistakes and blunders is considered impolite! May be like the limitations of UI mentioned, language also has its limitations and words mean different to different people. Or may be the perpetrators and sufferers do not share the same emotional levels.

2. ...the suggested changes are utterly insignificant at UI resolutions
Please see the first set which you may not have bothered to open, so here is an embedded png

Dropping a stem is insignificant?

The people who have designed it and now expressed their opinions are not condemned to read it ever. We who may have to read it will have to suffer it every day.

As John said, the later versions of the font do not drop the stem. As for getting a new version into the auto-update process... if you were to encircle India by road, walking, and set off today, it still would not have reached the update servers by the time you finished the walk.

>Dropping a stem is insignificant?

Yes and no. But the significant thing was, in this thread, John Hudson said... that was a bug, and... it was fixed?

So, I'm on to the rest.

And the rest looks more like an opportunity than a problem. I mean so what if the rest is good, sell the difference.

This paragraph cogently articulates the urgent problem that plagues most non-Latin type today:

'I fail to understand why type design is still considered 'white man's burden': to uplift and civilise others. Even when there are capable people in those languages, the decision makers prefer people who do not speak, write, read or understand the language to those who do. And the damage done is for all to see. When you point out the blunders, you are asked to be polite. You make blunders and I have to apologetic? Type colonialism?'

I take some issue with the perceptive suggestion that there is not a lot you can do when limited by stems that are just one pixel wide. That is true. And it is clever. But let's take a technological time trip back to the 1970s and 1980s. Thousands of lower ASCII (i.e. basic English) fonts were designed on minute pixel grids, such as 8x8. These fonts were not only legible but idiomatic. Hundreds were pleasing, and dozens were even beautiful.

This amazing achievement was possible because the designers had absorbed the letterforms along with their mothers' milk.

So how do we achieve results of comparable quality for non-Latin small-grid fonts? By learning to put our trust only in designers who are working with the forms they have grown up with. The alternative is bad type and opening up ourselves to the just charge of cultural imperialism and worse, crassness.

I also take issue with the argument that the economics do not justify investment in better non-Latin type. First, the money is abundantly there, both for Microsoft and Apple. Second, just consider that in many cases, you can pay the very best non-Latin type talent a mere fraction of what you pay the American or Western European designer. The fact that you still can pay the best non-Latin type talent so little is a broader legacy of historical imperialism. It's a legacy we need to keep in mind. Because we are perpetuating that legacy every time we choose white guys to design type for the rest of the world.

This would appear to be an opportunity for local designers.
Why don’t you have a go, Hashim?

Corporate type designs are rarely to my taste, but there’s no point in my trying to get them to design differently, because they are corporations.

Now you may say that’s “only aesthetics”, and this is a different issue. But I don’t think so. It’s all politics.

Bill, so the white man must find that non-white script designer who can design the single perfect version of that non-white script that every single non-white user will love, or else. If that don't happen, the script is dam-aged, the language screwed, the people and their culture... lost forever, and no one should ever make another, or a better version of that script again.

Got it.

Thanks Bill for being sympathetic to my cause. I thought every one else had ganged up against me!

One needs to cross the fence to know how the people who use the language feel when their letterforms are being distorted and mutilated in the name of UI, lack-of-time, product cycle and what not, but never admitting their lack of knowledge of the language or script to design a passable typeface for it.
I had been approached to design typefaces in Punjabi and Arabic before, but I had politely declined, because I knew I can never do an honest job without knowing the language or its culture. Even though I can read, speak, write and understand Hindi reasonably well, I would not dare to design a typeface for it, for the same reasons. How much should one know a language or script to design a typeface in it? Should he/she read/write/speak/understand/recognise the script or language? Would being good at one script be enough to design in any other?

Nick, I have designed nearly 30 typefaces in Malayalam which are being used in print and electronic media and will be designing more. Despite using ASCII, we had found our own indigenous ways to compose type on computers in our language for last 30 years. Now that Unicode makes it possible for all languages to coexist, we don't want all the progress in type design we made in the last 30 years to be demolished with crude and clumsy shapes and solutions imposed on us for any number of reasons.

David, the question is not about the perfect form, but a form that is acceptable for the intended users. And I don't think that is asking for too much. A similar observation made years back (http://typophile.com/node/51298) which was definitely more polite did not bear any result.

As Reynir had pointed out the fix may take a long time or may never ever reach all and if some of the users assume the stem-less letter to be correct, being the default font, whom do you blame? Very soon we might be seeing blogs, websites and even books and ads where this frequently used letter may laugh at us.

Should I still make 'polite' enquiries?

Better yet, solve the problem, then work to make your solution *the* standard so that others' brokenness won't matter. Of course, you will have to make sure that your solution does not break under any circumstances.

One (probably last) brief comment on this topic:

I wouldn't leap to any general conclusions based on a particular font development project, especially not one so tightly constrained by technical considerations, product development cycles, code lockdowns, bug fixing cycles, etc.. I've worked on enough very large projects to know that unless you are aware of all the details, it is unwise to presume anything about the decisions that were made.

With regard to the designers we decided to work with on the Nirmala UI project, the timeframe of the project encouraged us to work with people with whom we already had experience and knew we could rely on to meet deadlines and work closely with Fiona during revision cycles. In practice, this meant selecting designers from among Fiona's former students in the MA in type design programme at Reading, all of whom had experience with Indic scripts, could produce artwork to my technical specifications, understood our workflows and toolset, etc.. If we were making the designer selection now, or even a year after we began the project, we would have been able to meet those criteria and also work with designers from India, because a number of excellent Indian students have been through the Reading MA programme recently: Vaibhav Singh, Kalapi Gajjar-Bordawekar, Neelakash Kshetrimayum. Neel has worked with us on Bengali newspaper typefaces, and on the semilight weight of Nirmala Bengali, as well as other projects.

I expect, going forward, that sort of collaboration will become more common and progressively easier than it was. In the past two years, more western type designers have visited India and vice versa than probably at any other time in history. Connections are being made, people are finding ways to work together and, perhaps most importantly, friendships are being formed. We know more now about what is happening in India designwise, who to talk to about specific scripts, etc..
_____

If there is a general lesson to be learned from the specifics of the Nirmala UI project, it is this: if you are designing an entire operating system user interface around a typographic grid, don't presume that the same grid will work equally well for all writing systems. That seems to me a much more important issue than anything in the design of a font that had to struggle with the consequences of getting that presumption wrong.

So, what then, I wonder, are the minimum ppm requirements for each of India's official scripts.

If one defines some criteria, it's possible to answer that question. In the case of the Nirmala UI fonts, where the target ppem was fixed, we had to define 'minimum requirement' in terms of decipherability, which is much lower than the normal requirements of the scripts and readability. If one instead asks, as one should, what are the minimum requirements to display text according to the common norms of the script as applied to a given language, being faithful to the normal proportions of letters, conjuncts and marks and their positions relative to each other, then the ppem sizes required are a lot larger. And counting the pixels required for the tallest and deepest glyphs (plus marks) in each script doesn't help you deal with grids for multiscript text. It isn't simply the case that most of the Indian scripts require more pixel height than Latin in order to be readable, but that they make different use of the vertical height, most often with more pixels required below the baseline (common baseline alignment was another of the constraints on the Nirmala UI project: we were not able to do what used to be done for Arabic in some UI fonts and raise the baseline of entire scripts).

If one looks at Malayalam, the most vertically complex subjoined letter is -Ja, which requires at least 6 pixels in height to be legibly rendered in a fairly simple style; then you ideally want a space between the subjoined letter and the base letter, so that's a minimum of 7 pixels below the baseline (as against the 3 that we had to work with for Nirmala UI!). To determine the number of pixels needed above the baseline, one then has to figure how much vertical space the most complex base letter requires when proportional to that subjoined -Ja. I'm estimating that by the time you've taken that into account and also made above base allowance for virama and reph marks, you need something like 25 pixels.

But that's assuming that a single pixel stroke weight is being used for the subjoined -Ja, which has design implications for base letter stroke weight, especially in asymmetric rendering environments. If one harmonises the stroke weights -- typically meaning that the weight of the base letters will be slightly heavier than that of the subjoined letters --, then the base letters will be very light. If one makes the weight of the base letters appropriate to their size, then there will be a dramatic difference between the base and subjoined glyphs, especially if displayed at larger sizes or higher resolutions. So the question of what is the minimum ppem requirement cannot be answered, for a non-bitmap font format, independent of the design weight, and that's not even introducing bold style into the equation.

All of which is to say that while high resolution screens are even better news for Indian readers than they are for English readers, design solutions that aimed to solve technical issues around 9pt at 96ppi will not scale well to those higher resolutions, or to larger type sizes. We've made a semilight version of Nirmala UI for use at larger sizes in the Win8 UI (e.g. the 'Start' page label), in which we're able to better harmonise stroke weights between base and subjoined letters, among other things, but we're still stuck within the Segoe UI metrics and the inflexible grid.

So you really need about twice the height you have to make things look decent. Big Ten-Ouch.

In a specifically UI context, I would settle for 21 ppem to make Malayalam legible, I think. That would involve a design in which the subjoined forms were closer in scale than usual to the, proportionally smaller, base forms.* I'd take 9 pixels for the base height, plus seven below the baseline for the subjoined depth, plus four above for virama and reph, plus one for built in leading (a luxury we didn't enjoy for Nirmala UI). That's probably the bare minimum height to do reasonable justice to the writing system. It would be a very size-specific solution, and not at all suitable for document or print use.

The Segoe UI OS/2 metrics afforded us a total WinAscent-to-WinDescent height of 15 pixels at 12 ppem (naturally 16 pixels, but one was trimmed off in the VDMX table). But only three of those were below the baseline, which was the really painful aspect: we had plenty to work with above the baseline for most of the scripts (in Telugu, we contextually raised entire clusters with GPOS to avoid clipping subjoined forms, but in a few cases this pushed attached above vowel signs too high, which we had to fix with hinting). So overall we were only 29% short of an optimal height, but in that crucial baseline area we were 57% short. To ameliorate this in the Malayalam, we introduced the vertically shortened and raised variant base letters, to gain us another pixel below, and allowed the subjoined letters to touch the base letters, so we ended up with subjoined letters being 2/3 the height they would need to be in order for them all to be clearly legible. A fair number of the Malayalam subjoined letters can be made reasonably clear in a 4 pixel height, but others have collapsing counters and are at best suggestive of the general shape.
_____

* It's worth pointing out, I think, that in the palm leaf manuscript tradition of South Indian scripts it is common for base and subjoined letters to be closer in size than has become conventional in typography.

> * It's worth pointing out, I think, that in the palm leaf manuscript tradition of South Indian scripts it is common for base and subjoined letters to be closer in size than has become conventional in typography.

Interesting. It's the same with Burmese; in fact often the subjoined letters (especially medials) and superscript vowels are larger than the base letters.

I suspect the convention of small subjoined letters in South Indian typography is the result of accommodating the limitations of previous imported technologies, as well as reflecting the new kinds of publications being produced (for example, newspapers). In contrast, some of the Southeast Asian scripts retain their large subjoined forms in type, especially, as you note, for medials. I made a Javanese font this year -- debuting in the TypeCon exhibition next week --; now that's a script that doesn't skimp on descenders!

That sounds logical; I also imagine in the case of Burmese, consonant clusters (and ligatures) are generally used only in Pali words (and, as a kind of shorthand in a select few everyday words) and so don't appear very frequently. Having these glyphs larger than the base letters requires more linespacing, which is an undesirable compromise for the scarcity of subjoined consonants. Medials are very common, but as they generally attach to the base letters (no gap) they don't need as much vertical space.

Looking forward to seeing images of your Javanese.

I think the most important lesson one should learn from this exercise is that people who know the language and script should be involved or consulted when designing for it.

Fiona Ross had designed Linotype Malayalam typeface for phototypesetting system nearly three decades back and from the best information I could gather,
1. the design was based on the exisiting hot-metal designs
2. help from local artists was taken
3. a few round of corrections were made before it was adopted

Unlike now, designing for phototypesetting technology was not commonly available at that time to all and very few could have designed for it. I am sure technical limitations and time constraints were there even then, but the very fact that Linotype Malayalam is still perhaps one of the most the popular type designs after being adapted to the desktop by others speaks for itself. The typeface still has a few flaws in it and when I had the good fortune to meet the Fiona at Heidelberg a few years back at Linotype's Typotechnica, we did not get time to discuss finer details.

The very fact that people fluent in their respective languages are being chosen to collaborate is a healthy sign and will help much in making the designs conform to the requirements of the language. Careless chops, unacceptable shapes and clumsy solutions can be avoided if a person knowing the language and script is involved in the process. I would also request that instead of considering a one-year degree from one particular institute as a prerequisite for designing typefaces for world scripts, it would also be wise to give importance to talent and proficiency in a language and script. Also consultation and collaboration are much easier nowadays that it was three decades back.

From the earlier Kartika debacle, one can learn that it is foolhardy to expect that one person fluent in one Indian language or script will be fluent in every other. India has dozens of scripts and in the worst case, the difference between two scripts can be as much as Latin is to Chinese. The whole purpose of Unicode is defeated if scripts are distorted to fit into some technical grids and parameters.

After two faulty attempts, hope the next version of the software does some justice to Malayalam among other scripts.

I find nothing to disagree with in what you have said in this last post, Hashim. Yes, consultation with native typographers is definitely desirable, and is most often part of our process. Clearly, Nirmala UI Malayalam would have benefited from that also, not least because Fiona had so many other things on which to advise on this project. Another pair of eyes, such as yours, would have surely caught the serious bug with ഞ്ഞ that both she and I missed. I apologise for that oversight, and for the unconventional design solutions we had to implement to deal with Malayalam within the constraints of the UI metrics and target sizes. As I wrote much earlier in this thread, the nature of user interface fonts is such that I believe they should not be presented in application font menus, so that users are not tempted to use them in document. Alas, this is not the case, and as you say this means that mistakes and technical compromises present in such fonts may proliferate in documents.

Thanks John.
That is precisely the point I was trying to make.

Nir-mala denotes no fault (mala)
Sa-mala denotes with fault (mala)

Simply rename Nirmala to Samala.

John: "As I wrote much earlier in this thread, the nature of user interface fonts is such that I believe they should not be presented in application font menus, so that users are not tempted to use them in document" ...

I think you mean the nature of user interface fonts on Windows, or any combination of low res and non-std TT scaling and rendering.

"...design solutions that aimed to solve technical issues around 9pt at 96ppi will not scale well to those higher resolutions, or to larger type sizes"

This is Cleartype is not suited for India.... and... let's see...

Let me rephrase: it should be possible to decide whether or not a given font intended for use in the operating system UI or similar environment-specific use is also made available as a document font. It shouldn't be the case that every font used by the system also shows up in e.g. the Word font menu. I don't think this notion is particular to Windows. There is a long history of fonts designed for very specific purposes and conditions that tend not to work well as document fonts, and it seems to me reasonable that user access to such fonts might be restricted.

On MacOSX, for example, the font used in the Japanese UI is not listed in the font menu.

PS. UI fonts constitute part of the visual branding of an operating system or other piece of software, so restricting access to their use also seems reasonable in terms of avoiding brand dilution. In Windows 8, the lighter weights of Segoe UI are a prominent part of the 'look and feel' of the operating system, and making the same fonts available to users seems to me unwise.

"... and making the same fonts available to users seems to me unwise."

Well, grab a time machine and kill Frutiger's mom then why don'tcha?!

...the helveticarutiger international style of plain, which nearly all sides and scripts have adopted as their Geneva, is, I think, an attempt to appear as public spaces do in the brick and mortar world of street signs, building, road and airport navigation, and much more. Quietly authoritative, and with no opinion or attitude. Imaging "Arrivals" e.g. in Segoe, is not too difficult.

Now, if some font is handicapped for anything but the UI, sure, don't let that loose... But that should not have to happen. These fonts should be paragons of virtue, suitable as templates for type designs in their wake, for ui use on the os, and for all manner of composition and output.

And, I think there are a lot of ways to skin a UI font issue. If you are poor, you use system ones, or open source ones... If you want to stay unique you make ones that work in your world and not in anyone else's. I have seen all of this, but never have I heard a type designer complain they didn't like them. Never.

These fonts should be paragons of virtue, suitable as templates for type designs in their wake, for ui use on the os, and for all manner of composition and output.

I would have loved that to be the case with Nirmala UI, but the metrics constraints were a massive obstacle. There is much that is good in the fonts -- some of the script designs have been praised by native users --, much that would be adaptable to document fonts freed from the UI constraints, but only a few of the scripts (Tamil, Gurmukhi, Sinhala) get away without some amount of abuse to make them work within the Segoe UI metrics.

I'm not persuaded by the arguments about the limitations imposed by the Segoe UI metrics. Of course there are constraints. But only a native designer (of great skill) can make acceptable choices within those constraints. It is clear from this thread that there was no substantive consultatation with a native designer, which is a surprising omission on Microsoft's part. What could it possibly have added to the overall cost? Naturally the consequence is a disaster.

It would certainly be interesting to see if an Indian designer could have done a better job, given constraints that sound extremely tough.

Bill, John had finally admitted that "consultation with native typographers is definitely desirable, and is most often part of our process". Which means there was none of the kind in the case of Nirmala Malayalam. He had also suggested collaboration and consultation as the way to go in future to avoid more such disasters. My fond hope is that they keep their word. Otherwise people like me may have to bring this issue up again after four years!

And Bendy, India has good design schools and skilled type designers who have designed many typefaces that are in use in the thousands of publications in each script. Wouldn't you think that they who have known their script for years know better what is good for them that those who are probably seeing it for the first time in their life?

>Wouldn't you think that they who have known their script for years know better what is good for them that those who are probably seeing it for the first time in their life?

Any designer who has been through the Reading programme will definitively *not* be seeing Malayalam "for the first time in their life". And of course familiarity with a writing system doesn't always match up with being a good designer.

>India has good design schools and skilled type designers who have designed many typefaces that are in use in the thousands of publications in each script.

It sounds like it may be helpful to give that info to MS, especially any UI type designers.

>finally admitted that "consultation with native typographers is definitely desirable, and is most often part of our process".

Do you really think this occasion marks the first time anyone uttered those words? This concession has been conceded so many times it's in the Guiness Book of Records.

Here's an example to illustrate the problem. Your grid is a generous 12 pixels high. How many pixels will you give the upper segment of the stem of t? This is a hard decision for a Latin script designer to make even when the resolution is 1000x1000; even when it is 15,000x15,000. Will one pixel be too little in fast on-screen reading? Will three pixels be too much?

These questions can only be answered by someone who lives and breathes the alphabet every day. The more I think about it, the more I am saddened that anyone would routinely suppose they could design an 'Other's' alphabet.

Very true Bill. It is an unfair world, where the people for whom it is meant to be often have no say in what they would like. Decisions are often made arbitrarily and imposed. This happens in almost every field and type design could be no different. One can only hope that the decision makers consult, collaborate and take feedback at least before they release a typeface with which they are not native. Excuses like technical limitations, time constraints and what not only demonstrate their carelessness and mindlessness which was raised and denied. Since one of them have admitted their mistake, we will to leave it there. At least after two mistakes, they might turn wiser next time.

And Bendy, in my opinion, type design and language proficiency need n't be mutually exclusive. There are type designers who are proficient with the script and they might be better suited for such jobs than type designers who are just familiar with a script or who are just exposed to it. I am not familiar with the one-year Reading programme and cannot assume that they teach languages and scripts there. Deeper study, better role models and a willingness to consult is another way of preventing such mishaps, if one lacks proficiency in the script.