A. It’s a tradition.
Last month I mentioned the 25 year old RM Nimbus PC-186 and its 640x250 display. 250 was the number of lines displayable on a ‘CGA’ class CRT monitor of that time (more precisely at 50/60Hz non-interlaced). The 14" CGA was the only mass produced monitor available at a reasonable price in 1985 and it was that fact as much as the cost of the driver electronics that influenced the low resolution choice of display mode. By 1988, 14" ‘VGA’ type monitors were in mass production at 640x480 resolution and these soon gained higher definition 800x600.
During 1987-1993 one part of my job with RM involved working with a series of US Silicon Valley based companies who were growing the capabilities of PC graphics systems into the affordable market. Computer graphics has always been a personal interest so it was fun to be involved in bringing out the then emerging technology that is nowadays is taken for granted. My main role was writing device drivers for Windows and working with the chip designers to boost performance. During this period, the ‘holy grail’ was to reach 1024x768 24bit colour with an inexpensive design, a point we reached for the first time with a Cirrus Logic chip in 1993. This hit acceptable performance goals for Windows 3.1, removing the need for the transient 256 colour type displays popular for a while but problematic from an application programming point of view.
Two flies in the ointment. 1. Computer monitor manufacturers took a long time to come around to the obvious fact that 14"/15" CRT displays were too small for applications like word processing and spreadsheets. The sweet spot was 17"/19" but it seemed to take forever before it was accepted this was a volume market and the price benefits of mass production held sway (21" and above were cool but too unwieldy in CRT except for specialist applications such as CAD). 2. Most employers, schools and universities regarded it as acceptable to save a hundred dollars or so even if that meant seeing armies of highly paid employees and students hunched over small monitors peering at a fraction of a spreadsheet or page of text.
So much for history, though I’ll repeat the point that it seems to be a well-established tradition to use displays that are too small for purpose. Eventually things get better so nowadays good flat screen displays for desktop computers are very affordable. Although last year I visited the newsroom of a popular newspaper and it was almost laughable to see journalists and typesetters using displays that were obviously too small to efficiently work with a tabloid format. All to save the cost of a lunch or two!
Moores Law in the twenty first century. Electronics shrinking to give high functionality with reduced power consumption, and the consequential growth of small format computing: laptops, netbooks, smartphones, tablets, eBook readers. In each case the same pattern. Early devices have less than usable screen sizes and not just for reasons of manufacturing cost. Product marketing tries to avoid the fact that the emperor has no clothes. Keen leading edge users, in denial, claim its all ok. Markets learn and devices gradually move to something more ergonomic and pleasant to use.
This topic came to mind while I was tweaking an InScribe design for netbooks (typically a usable 1024x600 10" display nowadays after that unfortunate early fad for the 90s-retro 800x480 resolution on 7" in 2008). Reading today’s announcement of the upcoming RIM ‘PlayBook’ device (7" LCD, too small for its aspirations in my opinion. See the, I expect ill-fated, Dell Streak.). Not that 7"/8" is a bad format for many purposes (Note to Amazon with the 6” Kindle. And Sony. Try measuring a paperback book!).
Incidentally whatever the flaws in the first generation iPad, 9.7" is not dramatically smaller than the optimum size for purpose so kudos to Apple for bucking the usual pattern (although I personally think 11-12" touchscreen hits the right compromise between portability and function).
So if you find yourself peering at the internet through a 3.5" supposedly state of the art smartphone remember that for users to suffer for a while is a tradition, you are paying the price of being a part of history in the making, and things will soon get better (better for smartphones I suspect means about a 4.2-4.5" with narrow bezel compromise in current tech).
PS. Inches not metric; another tradition.
Monday, 27 September 2010
Thursday, 23 September 2010
Document embedding and OLE
There are a number of technical issues concerned with what I'm attempting to accomplish with the InScribe software. The biggest thorn in my side is the issue of embedding, visualising, and editing embedded data in compound documents. This is therefore something of a background note on the topic.
The notion of embedding or linking an ‘object’ in a document is commonplace. Web pages incorporate pictures, videos and specialized objects such as Flash or Silverlight interactive components. Word processing documents likewise contain objects, sometimes interactive objects, alongside the text. The idea of ‘compound document’ goes back to the 1980s.
The current situation with embedded objects is chaotic. Examples. Microsoft Office and Open Office, the two most popular office suites, have different schemes for add-ins. Even limiting attention to one vendor, Microsoft Office has added features in the 2003, 2007 then 2010 editions: all well and good but makes it difficult to support a diverse user base (Office 2003 is still widely used). Firefox, Chrome, Internet Explorer each has its own plugin approach and the story gets more complicated when considering non-Windows Internet browsers.
We are sorely missing standard, flexible, open approaches to embedding. On the web side of the coin, HTML5 is a move in the right direction though in itself no panacea despite what some less technically minded commentators may say on the subject (a topic for a future blog entry!).
A concrete example. There is no bottom line hardware-related reason nowadays that a simple photo editor plug-in software component could not operate on devices as diverse as eBook readers, smartphones, tablet computers, as well as notebook and desktop computers. Such a plug-in could enrich many applications, not only web browsing but word processors and camera management tools. In our Babel like world of 2010, to accomplish such a thing in software would involve writing versions for iOS, OS X, Android, Windows XP, Windows 7, Symbian, Kindle, Blackberry, Gnome, Wii... the list goes on. The developer then needs to tackle application-specific rules for plug-ins (if such exist). A relatively simple piece of software is almost impossible to deploy widely.
I am not advocating one ring to rule them all, simply highlighting the severe lack of standard ways for applications and components to interoperate and deploy.
In fact, for Microsoft Windows applications there has been one solution for almost 20 years. OLE (Object Linking and embedding) was introduced to Windows in 1990 and expanded substantially to version 2 in 1993. Parts of the OLE system were renamed ActiveX controls in 1996. I’ve exploited OLE with the InScribe software to enable in-place editing of Ancient Egyptian in Word Processing and other applications.
OLE has never been an ideal technology solution. Parts are overcomplicated and error prone during development. OLE design is too specific to classic Windows architecture. There was originally insufficient attention given to security issues although this is now largely addressed. Nevertheless, for Windows applications, OLE provided some solutions to the big problem of making applications and components work together by defining standard rules for interoperability of functions like embedding and compound documents.
Unfortunately, OLE development by Microsoft pretty much stopped well over a decade ago, more a victim of fashion rather than any logical reason I suspect. One side effect is that something as fundamental as how copy and paste works between Windows applications is still stuck in a 1990s time-warp.
As the internet grew and new technologies such as Java and .Net became available, inasmuch as there was any attempt to address application interoperability, solutions tended to be product specific. Microsoft themselves targetted ‘the enterprise’ with less focus on the general personal computer user. Rather than an OLE philosophy where third parties can expand the capabilities of Windows and its applications in a general way, Microsoft Office became focussed on enterprise oriented Office specific add-ons. Linux and other alternatives failed to rise to the challenge of developing a more open and flexible approach.
OLE continues to be supported in Windows and Office, but pretty much maintenance only. OpenOffice and other products continue likewise. I have not looked at the latest Adobe Creative Suite (CS5) but recall an earlier move around CS3 to remove some OLE functionality. Microsoft Office Word 2010 runs OLE embedding in a compatibility mode. I don’t expect OLE to disappear in the next few years but it is certainly becoming less usable.
If anyone reading this understands why the issue of application interoperability and OLE type functionality is missing from .Net and WPF I'd be delighted to find out.
This slow decline of OLE and the lack of practical modern alternatives proved a stumbling block in my development of a new version of the InScribe for Windows software. I expect other developers are in a similar situation of having to make some undesirable compromises in order to get a product released. On a positive note, the problem has stimulated a number of interesting ideas for future directions and I hope to touch on these here during the next few months.
Meanwhile a call for anyone working on document embedding to please learn from the past. Lets try to ensure whatever is latest and greatest at least accomplishes what OLE did 20 years ago (and still almost does).
The notion of embedding or linking an ‘object’ in a document is commonplace. Web pages incorporate pictures, videos and specialized objects such as Flash or Silverlight interactive components. Word processing documents likewise contain objects, sometimes interactive objects, alongside the text. The idea of ‘compound document’ goes back to the 1980s.
The current situation with embedded objects is chaotic. Examples. Microsoft Office and Open Office, the two most popular office suites, have different schemes for add-ins. Even limiting attention to one vendor, Microsoft Office has added features in the 2003, 2007 then 2010 editions: all well and good but makes it difficult to support a diverse user base (Office 2003 is still widely used). Firefox, Chrome, Internet Explorer each has its own plugin approach and the story gets more complicated when considering non-Windows Internet browsers.
We are sorely missing standard, flexible, open approaches to embedding. On the web side of the coin, HTML5 is a move in the right direction though in itself no panacea despite what some less technically minded commentators may say on the subject (a topic for a future blog entry!).
A concrete example. There is no bottom line hardware-related reason nowadays that a simple photo editor plug-in software component could not operate on devices as diverse as eBook readers, smartphones, tablet computers, as well as notebook and desktop computers. Such a plug-in could enrich many applications, not only web browsing but word processors and camera management tools. In our Babel like world of 2010, to accomplish such a thing in software would involve writing versions for iOS, OS X, Android, Windows XP, Windows 7, Symbian, Kindle, Blackberry, Gnome, Wii... the list goes on. The developer then needs to tackle application-specific rules for plug-ins (if such exist). A relatively simple piece of software is almost impossible to deploy widely.
I am not advocating one ring to rule them all, simply highlighting the severe lack of standard ways for applications and components to interoperate and deploy.
In fact, for Microsoft Windows applications there has been one solution for almost 20 years. OLE (Object Linking and embedding) was introduced to Windows in 1990 and expanded substantially to version 2 in 1993. Parts of the OLE system were renamed ActiveX controls in 1996. I’ve exploited OLE with the InScribe software to enable in-place editing of Ancient Egyptian in Word Processing and other applications.
OLE has never been an ideal technology solution. Parts are overcomplicated and error prone during development. OLE design is too specific to classic Windows architecture. There was originally insufficient attention given to security issues although this is now largely addressed. Nevertheless, for Windows applications, OLE provided some solutions to the big problem of making applications and components work together by defining standard rules for interoperability of functions like embedding and compound documents.
Unfortunately, OLE development by Microsoft pretty much stopped well over a decade ago, more a victim of fashion rather than any logical reason I suspect. One side effect is that something as fundamental as how copy and paste works between Windows applications is still stuck in a 1990s time-warp.
As the internet grew and new technologies such as Java and .Net became available, inasmuch as there was any attempt to address application interoperability, solutions tended to be product specific. Microsoft themselves targetted ‘the enterprise’ with less focus on the general personal computer user. Rather than an OLE philosophy where third parties can expand the capabilities of Windows and its applications in a general way, Microsoft Office became focussed on enterprise oriented Office specific add-ons. Linux and other alternatives failed to rise to the challenge of developing a more open and flexible approach.
OLE continues to be supported in Windows and Office, but pretty much maintenance only. OpenOffice and other products continue likewise. I have not looked at the latest Adobe Creative Suite (CS5) but recall an earlier move around CS3 to remove some OLE functionality. Microsoft Office Word 2010 runs OLE embedding in a compatibility mode. I don’t expect OLE to disappear in the next few years but it is certainly becoming less usable.
If anyone reading this understands why the issue of application interoperability and OLE type functionality is missing from .Net and WPF I'd be delighted to find out.
This slow decline of OLE and the lack of practical modern alternatives proved a stumbling block in my development of a new version of the InScribe for Windows software. I expect other developers are in a similar situation of having to make some undesirable compromises in order to get a product released. On a positive note, the problem has stimulated a number of interesting ideas for future directions and I hope to touch on these here during the next few months.
Meanwhile a call for anyone working on document embedding to please learn from the past. Lets try to ensure whatever is latest and greatest at least accomplishes what OLE did 20 years ago (and still almost does).
Tuesday, 24 August 2010
Mangaglyphics
Apparently the Japanese word manga (katakana マンガ, kanji 漫画, hiragana まんが) can be loosely translated to English as “whimsical pictures”. Distinctive manga styles have seen growing popularity outside Japan during the last few decades predominantly through comic book, cartoon, and video game formats.
Some time ago I had the crazy notion that there are some interesting ways to combine the tradition of ancient Egyptian Hieroglyphs with manga styles in an entertaining way, mangaglypic seemed like the word rather than the equally obvious hieromanga. Fun, possibly with some educational value.
However with the work that needs to be done on improving accessibility to non-whimsical applications of ancient Egyptian on personal computers and other devices mangaglyphic is pretty low on my software to do list.
So why mention the term right now? Partly because it looks like a mangaglyph or two are creeping unasked into the InScribeX Web user interface. Partly because I’d be delighted to hear from artists or others experimenting with this style of image. However what actually stimulated my writing today was discovering the search engine bing.com still returns zero results for mangaglyphic or related words and google.com returns only one result. So in the unlikely event the term catches on at all I wanted to state mangaglyphic is meant to be a generic word. No attempts to register trademarks etc. please.
Some time ago I had the crazy notion that there are some interesting ways to combine the tradition of ancient Egyptian Hieroglyphs with manga styles in an entertaining way, mangaglypic seemed like the word rather than the equally obvious hieromanga. Fun, possibly with some educational value.
However with the work that needs to be done on improving accessibility to non-whimsical applications of ancient Egyptian on personal computers and other devices mangaglyphic is pretty low on my software to do list.
So why mention the term right now? Partly because it looks like a mangaglyph or two are creeping unasked into the InScribeX Web user interface. Partly because I’d be delighted to hear from artists or others experimenting with this style of image. However what actually stimulated my writing today was discovering the search engine bing.com still returns zero results for mangaglyphic or related words and google.com returns only one result. So in the unlikely event the term catches on at all I wanted to state mangaglyphic is meant to be a generic word. No attempts to register trademarks etc. please.
Thursday, 12 August 2010
My first Home PC – recollections of the RM Nimbus PC-186
Despite having recently mentioned the Jupiter Ace and Sinclair Spectrum, early hobbyist computers, I am happy to admit to never owning either of those devices being far too impatient an individual to work with cassette tapes and the like. So I was never an early adopter of computers outside work and my personal home computer journey began in 1984.
The RM Nimbus PC-186 was released sometime in early 1985 - I recall demonstrating a beta-release of Windows (version 1) on the Nimbus to journalists visiting BETT 85 (British Educational Training and Technology Show). Incidentally BETT (www.bettshow.com) has grown to be the major annual event for information technology in UK Education, now occupying the huge Olympia exhibition centre in London for several days each January. But I digress.
Released just around the time that ‘IBM compatibility’ became fashionable for Personal Computer design, the Nimbus used an Intel Processor (80186) to run MS-DOS (3.x) but made no attempt to match the hardware compatibility points of an IBM PC. This was not unusual in the early 1980s; here in the UK, non-IBM-compatible MS-DOS computers from Apricot Computers were popular in some commercial sectors around the same time.
RM (then officially Research Machines Limited, www.rm.com/) was already established as one of the leading suppliers to UK education with the RM 380Z and 480Z computers, both 8 bit machines using CP/M with Z80 microprocessor. These were among the first small computers to make substantial use of networking; the 480Z was a very early example of a diskless workstation on a Local Area Network (LAN).
Working with RM at the time, I was fortunate to get my hands on one of the first batch of Nimbus prototypes in 1984 so my first home PC was this ugly but functional box with unfinished casework, an item for the study not the living room.
The Nimbus was the first 16 bit computer from RM. The combination of a faster processor than the IBM PC (8Mhz 80186 as against 4.77Mhz 8088), a larger maximum memory space (960K v 640K), and use of 3.5" 720Kb disks (v 5.25” 360Kb) raised some interest. A unique feature was ‘Piconet’, a serial interface for peripherals, a kind of early forerunner of USB, a good idea but before its time and let down by the performance of its implementation. My machine had a 10Mb hard drive, a luxury at a time when systems often had to make do with floppies or a LAN server. The Nimbus was a modest commercial success. I have no sales numbers to hand but certainly over 100K systems shipped to UK schools before RM adopted mainstream IBM compatible 286 then 386 based systems. The main competition in education was the Acorn/BBC microcomputer. Unlike the situation in North America, Apple never made much progress in the UK Education market largely due to high prices compared with Acorn and DOS based systems.
The Nimbus display was unique – a ‘high’ resolution graphics mode of 640x250 pixels with only 4 colours (black, white and a choice of the other two from the usual 14 suspects, I usually settled for red and blue). In modern terms that sounds like a nightmare. Indeed the reality was worse, just not quite so drab as the monochrome 640x200 (CGA) graphics used on the IBM PC or the 512x342 Apple Macintosh of the same era. A more colourful 320x250 display mode was used by most educational software for the Nimbus but I rarely used this 16-colour mode personally, my home computer activities largely involving software development, word processing and spread sheet applications. My campaign for usable graphics on personal computers was already underway by then but that is another story.
My software 1984/5. TXED, the RM full screen text editor, was useful. I created the Nimbus ports of Microsoft Word (for DOS) and Microsoft Multiplan (the DOS-based predecessor to Excel) for RM. This combination made for basic PC office productivity applications and it was bundled as such with a range of Nimbus configurations. For software development, I learned C and the new C++ programming language. However assembly language programming was still crucial for these low memory slow systems. My largest assembly project was an adaptation of Microsoft Windows 1.x to the Nimbus.
It is a reflection on the limited applications at that time I suppose that this development work was about the most entertaining aspect of home computing in my early personal experience. Fortunately for children and teachers in schools, there grew a useful and sometimes fun catalogue of educational software and simple games for the Nimbus.
After around 18 months with the Nimbus PC-186 as my home computer, I upgraded to an 80286 IBM compatible for most activities although my Nimbus hung around for several years (and several revisions of Windows up to and including the 1990 release 3.0).
An interesting footnote on those early years of software development for Microsoft Windows. Curiously enough, the extra memory available over the IBM PC architecture meant that Windows on the Nimbus had about twice the memory available for applications once DOS and Windows fixed overheads were taken into account. It took until 1988 and early alpha versions of Windows 3.0 to enable an IBM compatible to win out in the memory stakes.
The RM Nimbus PC-186 was released sometime in early 1985 - I recall demonstrating a beta-release of Windows (version 1) on the Nimbus to journalists visiting BETT 85 (British Educational Training and Technology Show). Incidentally BETT (www.bettshow.com) has grown to be the major annual event for information technology in UK Education, now occupying the huge Olympia exhibition centre in London for several days each January. But I digress.
Released just around the time that ‘IBM compatibility’ became fashionable for Personal Computer design, the Nimbus used an Intel Processor (80186) to run MS-DOS (3.x) but made no attempt to match the hardware compatibility points of an IBM PC. This was not unusual in the early 1980s; here in the UK, non-IBM-compatible MS-DOS computers from Apricot Computers were popular in some commercial sectors around the same time.
RM (then officially Research Machines Limited, www.rm.com/) was already established as one of the leading suppliers to UK education with the RM 380Z and 480Z computers, both 8 bit machines using CP/M with Z80 microprocessor. These were among the first small computers to make substantial use of networking; the 480Z was a very early example of a diskless workstation on a Local Area Network (LAN).
Working with RM at the time, I was fortunate to get my hands on one of the first batch of Nimbus prototypes in 1984 so my first home PC was this ugly but functional box with unfinished casework, an item for the study not the living room.
The Nimbus was the first 16 bit computer from RM. The combination of a faster processor than the IBM PC (8Mhz 80186 as against 4.77Mhz 8088), a larger maximum memory space (960K v 640K), and use of 3.5" 720Kb disks (v 5.25” 360Kb) raised some interest. A unique feature was ‘Piconet’, a serial interface for peripherals, a kind of early forerunner of USB, a good idea but before its time and let down by the performance of its implementation. My machine had a 10Mb hard drive, a luxury at a time when systems often had to make do with floppies or a LAN server. The Nimbus was a modest commercial success. I have no sales numbers to hand but certainly over 100K systems shipped to UK schools before RM adopted mainstream IBM compatible 286 then 386 based systems. The main competition in education was the Acorn/BBC microcomputer. Unlike the situation in North America, Apple never made much progress in the UK Education market largely due to high prices compared with Acorn and DOS based systems.
The Nimbus display was unique – a ‘high’ resolution graphics mode of 640x250 pixels with only 4 colours (black, white and a choice of the other two from the usual 14 suspects, I usually settled for red and blue). In modern terms that sounds like a nightmare. Indeed the reality was worse, just not quite so drab as the monochrome 640x200 (CGA) graphics used on the IBM PC or the 512x342 Apple Macintosh of the same era. A more colourful 320x250 display mode was used by most educational software for the Nimbus but I rarely used this 16-colour mode personally, my home computer activities largely involving software development, word processing and spread sheet applications. My campaign for usable graphics on personal computers was already underway by then but that is another story.
My software 1984/5. TXED, the RM full screen text editor, was useful. I created the Nimbus ports of Microsoft Word (for DOS) and Microsoft Multiplan (the DOS-based predecessor to Excel) for RM. This combination made for basic PC office productivity applications and it was bundled as such with a range of Nimbus configurations. For software development, I learned C and the new C++ programming language. However assembly language programming was still crucial for these low memory slow systems. My largest assembly project was an adaptation of Microsoft Windows 1.x to the Nimbus.
It is a reflection on the limited applications at that time I suppose that this development work was about the most entertaining aspect of home computing in my early personal experience. Fortunately for children and teachers in schools, there grew a useful and sometimes fun catalogue of educational software and simple games for the Nimbus.
After around 18 months with the Nimbus PC-186 as my home computer, I upgraded to an 80286 IBM compatible for most activities although my Nimbus hung around for several years (and several revisions of Windows up to and including the 1990 release 3.0).
An interesting footnote on those early years of software development for Microsoft Windows. Curiously enough, the extra memory available over the IBM PC architecture meant that Windows on the Nimbus had about twice the memory available for applications once DOS and Windows fixed overheads were taken into account. It took until 1988 and early alpha versions of Windows 3.0 to enable an IBM compatible to win out in the memory stakes.
Saturday, 7 August 2010
Missing in Silverlight 4: a functional GlyphTypeface class
Warning. Obscurity level: HIGH.
This note is primarily aimed at the Silverlight development team in Microsoft Redmond. Other Silverlight developers may also want to understand a limitation of Silverlight 4.
Background
Applications that require superscripts, subscripts, and other rich text functionality need control of character/glyph positional placement. Advanced typography is also useful in applications such as e-book readers where it is often desirable to accurately represent the look and feel of the book. Specialist applications that do mathematical typography (and my ancient Egyptian work) need this kind of precision. From a developer perspective, it is the GlyphTypeface class in the .Net/WPF System.Windows.Media namespace that provides much of required functionality for WPF applications.
The problem
The Silverlight 4 documentation available from Microsoft (see http://msdn.microsoft.com/en-us/library/system.windows.media.glyphtypeface(VS.95).aspx) states
Er no! The WPF 4 version of GlyphTypeface indeed does this. However Silverlight 4 only supports reading the name of the font and its version number. All the useful functionality is missing. The documentation quoted only applies to WPF.
It is therefore impossible in general to implement advanced typography in Silverlight. A big hole - typography has been possible since Windows 3.1, the first release (1992) to incorporate scalable (TrueType) fonts. [Note: sure there are clumsy workarounds in very special circumstances but I won’t go into those today].
The solution
Expand the GlyphTypeface in Silverlight 5 to provide all missing functionality except where this conflicts for some reason with the Silverlight security model. In particular, discovery of the black box for a glyph is essential, as is CharacterToGlyphMap (without which the ‘Glyphs’ class has only limited use). A fairly small amount of straightforward work in the Silverlight runtime yields a big benefit to third party developers and should also help functional enhancement to controls such as RichTextBox.
Note: Windows Phone 7 is also lacking functionality here.
This note is primarily aimed at the Silverlight development team in Microsoft Redmond. Other Silverlight developers may also want to understand a limitation of Silverlight 4.
Background
Applications that require superscripts, subscripts, and other rich text functionality need control of character/glyph positional placement. Advanced typography is also useful in applications such as e-book readers where it is often desirable to accurately represent the look and feel of the book. Specialist applications that do mathematical typography (and my ancient Egyptian work) need this kind of precision. From a developer perspective, it is the GlyphTypeface class in the .Net/WPF System.Windows.Media namespace that provides much of required functionality for WPF applications.
The problem
The Silverlight 4 documentation available from Microsoft (see http://msdn.microsoft.com/en-us/library/system.windows.media.glyphtypeface(VS.95).aspx) states
| “The GlyphTypeface object is a low-level text object that corresponds to a single face of a font family as represented by an OpenType font file, or serialized as a block of memory in a document. Each glyph defines metrics that specify how it aligns with other glyphs. The correct GlyphTypeface to use for a run of characters in a given logical font is normally determined by the Silverlight font system. The GlyphTypeface object provides properties and methods for the following: · Obtaining font face common metrics, such as the ratio of ascent and descent to em size. · Obtaining metrics, outlines, and bitmaps for individual glyphs.” |
Er no! The WPF 4 version of GlyphTypeface indeed does this. However Silverlight 4 only supports reading the name of the font and its version number. All the useful functionality is missing. The documentation quoted only applies to WPF.
It is therefore impossible in general to implement advanced typography in Silverlight. A big hole - typography has been possible since Windows 3.1, the first release (1992) to incorporate scalable (TrueType) fonts. [Note: sure there are clumsy workarounds in very special circumstances but I won’t go into those today].
The solution
Expand the GlyphTypeface in Silverlight 5 to provide all missing functionality except where this conflicts for some reason with the Silverlight security model. In particular, discovery of the black box for a glyph is essential, as is CharacterToGlyphMap (without which the ‘Glyphs’ class has only limited use). A fairly small amount of straightforward work in the Silverlight runtime yields a big benefit to third party developers and should also help functional enhancement to controls such as RichTextBox.
Note: Windows Phone 7 is also lacking functionality here.
Tuesday, 3 August 2010
Ace Computers (Pilot and Jupiter)
In the interests of the online documentation of obscure connections.
Several years ago, I attended a celebration of the life of Alan Turing (1912-1954) at King's College Cambridge. Turing is recognized nowadays as an influential pioneer in the history of Computer Science and Computers. His key contributions to British code breaking work at Bletchley Park during World War II have historical significance. At the King's event, it was fascinating to meet several of the people who had worked with Turing; a reminder of how young computer technology really is.
This recollection came to mind recently while reading an article (How Alan Turing's Pilot ACE changed computing) on the BBC website. The Pilot Ace was an early computer designed by Turing and developed at the British National Physical Laboratory (NPL) from 1946 to its release in 1950. For several years, the Pilot Ace was used for commercial applications and can now be seen in the London Science Museum. The BBC article refers to a radio interview with Tom Vickers, operations manager on the Pilot Ace project (As of writing, the interview is still available via Harriet Vickers blog where the interview starts 11 minutes into the podcast).
An early home computer called the Jupiter Ace was released in 1982, an untypical device of its time based around the FORTH programming system, an approach that yielded a little more efficiency than similar machines of that era which were mostly programmed using interpreted BASIC.
Computing technology had advanced considerably since the era of the Pilot Ace 30 years earlier but the two devices in their own way illustrate the challenge of trying to work with hardware not quite ready for prime time yet interesting nevertheless. A basic Jupiter Ace came with 1024 bytes (1K) of main memory, expandable to 49x1024 bytes (49K). The Pilot Ace originally had 512 bytes main memory, later expanded to 1408 bytes (implemented using vacuum tubes!) with a 16K byte drum memory peripheral.
Now for the obscure part. The Jupiter Ace ROM software was written by Steve Vickers. Steve had already written much of the ROM software for the Sinclair ZX home computers, popular hobbyist type machines in the UK of the early 1980s. The name "Jupiter Ace" was inspired by the work of his father Tom Vickers on the Pilot Ace. Generations.
It is now 60 years since the Pilot Ace release. Almost 30 since the Jupiter Ace and the computing landscape has changed far more dramatically in the last three decades than in the first three following Turing's work. A myriad of observations could be made but I'll simply note that commonplace telephones nowadays have a billion times more memory than the Pilot, and hundreds of thousands more than the Jupiter.
Perhaps it is time for another Ace computer.
Several years ago, I attended a celebration of the life of Alan Turing (1912-1954) at King's College Cambridge. Turing is recognized nowadays as an influential pioneer in the history of Computer Science and Computers. His key contributions to British code breaking work at Bletchley Park during World War II have historical significance. At the King's event, it was fascinating to meet several of the people who had worked with Turing; a reminder of how young computer technology really is.
This recollection came to mind recently while reading an article (How Alan Turing's Pilot ACE changed computing) on the BBC website. The Pilot Ace was an early computer designed by Turing and developed at the British National Physical Laboratory (NPL) from 1946 to its release in 1950. For several years, the Pilot Ace was used for commercial applications and can now be seen in the London Science Museum. The BBC article refers to a radio interview with Tom Vickers, operations manager on the Pilot Ace project (As of writing, the interview is still available via Harriet Vickers blog where the interview starts 11 minutes into the podcast).
An early home computer called the Jupiter Ace was released in 1982, an untypical device of its time based around the FORTH programming system, an approach that yielded a little more efficiency than similar machines of that era which were mostly programmed using interpreted BASIC.
Computing technology had advanced considerably since the era of the Pilot Ace 30 years earlier but the two devices in their own way illustrate the challenge of trying to work with hardware not quite ready for prime time yet interesting nevertheless. A basic Jupiter Ace came with 1024 bytes (1K) of main memory, expandable to 49x1024 bytes (49K). The Pilot Ace originally had 512 bytes main memory, later expanded to 1408 bytes (implemented using vacuum tubes!) with a 16K byte drum memory peripheral.
Now for the obscure part. The Jupiter Ace ROM software was written by Steve Vickers. Steve had already written much of the ROM software for the Sinclair ZX home computers, popular hobbyist type machines in the UK of the early 1980s. The name "Jupiter Ace" was inspired by the work of his father Tom Vickers on the Pilot Ace. Generations.
It is now 60 years since the Pilot Ace release. Almost 30 since the Jupiter Ace and the computing landscape has changed far more dramatically in the last three decades than in the first three following Turing's work. A myriad of observations could be made but I'll simply note that commonplace telephones nowadays have a billion times more memory than the Pilot, and hundreds of thousands more than the Jupiter.
Perhaps it is time for another Ace computer.
Thursday, 17 June 2010
C++ vs. C# 2010 ... and the winner is ...
As far as I know there is no World Cup for programming languages, quadrennial or otherwise. No FIFA++ or FIFA# either. But, if there was...
I have been helping for several months with a project aiming to commercialise an optimising technique for microelectronic circuits discovered as part of some academic research at a local university. Who would predict that the mathematics of Galois polynomials would have an industrial application?! Well, this is my journal of total obscurity.
Writing the software. Apart from user interface, visualisation and usability all good stuff, a key element of the project is of course the algorithms, some of which require a lot of computational processing by current standards and can be time consuming (potentially days rather than hours or minutes).
The original research software used a C++ with STL implementation and much of the time I continued using C++ for algorithm work as an adaption of the original despite the fact I’m far more C# oriented nowadays. Mental exercise is a good thing. My Windows software design was a hybrid with the user interface and control functionality in C#/.Net/WPF with algorithms packaged in a DLL implemented in C++. Standard .Net interop linked the two components together.
I suspect most developers with strong experience in C++ and C# will agree that a modern language such as C# can be far more readable than C++. However a common concern is the efficiency of C# on the .Net and Mono environments using the Common Library Runtime (CLR) compared with C++ static compilation into native machine code. There is no question that C and C++ work closer to the metal and their compilers generate very efficient code in the right hands (C has been around since 1973 and C++ since 1983). The C/C++ combination remains the most efficient programming choice for some applications.
Question. What happened when I rewrote a key algorithm from C++ into C# using the same logic?
Answer. Performance improved by an order of magnitude. In fact my initial benchmarks were so close to exactly 10x faster I felt obliged to check and recheck. Memory usage for the C# version was about 5% less than C++ for this specific problem.
[In both instances C++ and C# I used Microsoft Visual Studio 2010 and .Net 4 runtimes but have since replicated similar figures on Linux using GNU CPP for C++ and MonoDevelop 2.2 with Mono 2.6.4 for C#.].
Understanding the why. Partly down to inefficiencies in the C++ heap and STL templates - software uses hashset/unordered_map/vector objects. Partly benefits of automatic lifecycle management of C# objects with a built in garbage collector. A little benefit from C# language features such as the foreach construction.
OK, I’m sure that by adjusting algorithms and replacing STL constructs I could bring C++ up to a similar or higher speed than the C# version. Plenty can be said on that topic. But life is too short for such antics especially when the C# version is more concise and readable that a C++ version could ever be.
Back in 2006 Italy lifted the trophy, C# and CLR implementations were not as mature, C++ held sway. Times change.
Now, Summer 2010, to my mind C# takes the top of the podium. Weighing the evidence, fact not opinion. Performance and elegance, it is so often a trade off but this, my recent experiment, sealed the question for me.
Postscript. I wrote this note to encourage other developers to look again at the rationale of choosing C++ over a modern programming language even for computationally intensive tasks. The usual caveats. Especially 1. existing systems where language change is impractical and interop inappropriate and 2. the limited class of problem where C++ still rules. Personally speaking. I'll continue to choose C or C++ where there is a clear benefit but the problem domain where this is true seems to have shrunk dramatically.
I have been helping for several months with a project aiming to commercialise an optimising technique for microelectronic circuits discovered as part of some academic research at a local university. Who would predict that the mathematics of Galois polynomials would have an industrial application?! Well, this is my journal of total obscurity.
Writing the software. Apart from user interface, visualisation and usability all good stuff, a key element of the project is of course the algorithms, some of which require a lot of computational processing by current standards and can be time consuming (potentially days rather than hours or minutes).
The original research software used a C++ with STL implementation and much of the time I continued using C++ for algorithm work as an adaption of the original despite the fact I’m far more C# oriented nowadays. Mental exercise is a good thing. My Windows software design was a hybrid with the user interface and control functionality in C#/.Net/WPF with algorithms packaged in a DLL implemented in C++. Standard .Net interop linked the two components together.
I suspect most developers with strong experience in C++ and C# will agree that a modern language such as C# can be far more readable than C++. However a common concern is the efficiency of C# on the .Net and Mono environments using the Common Library Runtime (CLR) compared with C++ static compilation into native machine code. There is no question that C and C++ work closer to the metal and their compilers generate very efficient code in the right hands (C has been around since 1973 and C++ since 1983). The C/C++ combination remains the most efficient programming choice for some applications.
Question. What happened when I rewrote a key algorithm from C++ into C# using the same logic?
Answer. Performance improved by an order of magnitude. In fact my initial benchmarks were so close to exactly 10x faster I felt obliged to check and recheck. Memory usage for the C# version was about 5% less than C++ for this specific problem.
[In both instances C++ and C# I used Microsoft Visual Studio 2010 and .Net 4 runtimes but have since replicated similar figures on Linux using GNU CPP for C++ and MonoDevelop 2.2 with Mono 2.6.4 for C#.].
Understanding the why. Partly down to inefficiencies in the C++ heap and STL templates - software uses hashset/unordered_map/vector objects. Partly benefits of automatic lifecycle management of C# objects with a built in garbage collector. A little benefit from C# language features such as the foreach construction.
OK, I’m sure that by adjusting algorithms and replacing STL constructs I could bring C++ up to a similar or higher speed than the C# version. Plenty can be said on that topic. But life is too short for such antics especially when the C# version is more concise and readable that a C++ version could ever be.
Back in 2006 Italy lifted the trophy, C# and CLR implementations were not as mature, C++ held sway. Times change.
Now, Summer 2010, to my mind C# takes the top of the podium. Weighing the evidence, fact not opinion. Performance and elegance, it is so often a trade off but this, my recent experiment, sealed the question for me.
Postscript. I wrote this note to encourage other developers to look again at the rationale of choosing C++ over a modern programming language even for computationally intensive tasks. The usual caveats. Especially 1. existing systems where language change is impractical and interop inappropriate and 2. the limited class of problem where C++ still rules. Personally speaking. I'll continue to choose C or C++ where there is a clear benefit but the problem domain where this is true seems to have shrunk dramatically.
Subscribe to:
Posts (Atom)