On Mon, Apr 12, 2010 at 11:41:59PM +0200, Hans Hagen wrote: > On 12-4-2010 9:43, Khaled Hosny wrote: > >On Mon, Apr 12, 2010 at 09:23:02PM +0200, Marco wrote: > >>>With MkIV \cap and \nocap is no longer necessary when you have a > >>>opentype font > >>>with the smcp (smallcapitals) and c2sc (capitals to smallcapitals) > >>>features. > >>Thanks for your explanation. But why doesn't your example work with the > >>latin modern fonts? Don't they have these features? I'd be surprised > >>when they don't have small caps. > > > >They don't have a small caps OpenType feature (smcp) for a reason beyond > >to me, they however have an old-fashioned separate small caps font. > > this is because they are cm compatible (the initial objective of the > project was a merge of all those variants) > > in the future we might have extra lm fonts that have those features > but the team is still not sure if this should be done ... it makes > much sense for consistency to have smallcaps merged in the normal > shapes but even then there would be a separate smallcaps font as > well
A separate small caps font made sense for Type1 fonts (where CM compatibility would matter), but for OpenType fonts I fail to see the reasoning for this. > >I would liked to send "patches" to LM fonts project, but they don't have > >a source repository and their work flow depends on proprietary software > >that I cannot afford. > > concerning the workflow you're wrong ... they use public tools like > metatype1 which is free ... and they're currently building a tool > chain for the math fonts I was referring to OpenType programming where they use Adobe AFDKO which is a proprietary software that run only on proprietary OS, and with lack of sources I can't even provide patches against the feature files, I can make modified fonts but I don't think they will accept it. Even MetaType1, it is written with only Windows users in mind; I can't use the supplied batch files and I can't understand them (with no documentation at all) to write a replacement. > concerning the repos you're right ... given earlier experiences with > lack of quality assurance in public fonts the lm/gyre project > follows strickt procedures and only the core team can patch ... of > course you can send suggestions and patches but the core team > decides Closed development is not the solution for lack of proper QA, proper QA is the solution; you can have open development model with public repos, bug tracker, roadmaps etc. and still maintain a strict QA process, there are many free software projects with very high QA standards but still running an open development model. With open development you encourage potential contributors who may or my not very valuable to you project. > fyi: the gyre team (gust font foundation) has now reverted to the > core urw fonts for which they got the copyright and it made it > possible to get rid of some ugly artefacts and glyphs (again, lack > of qa had rendered the latest public urw fonts somewhat useless) There is still a long way to go, the Greek glyph for example are ranging from suboptimal to pure crap. Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
