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.
Tuesday, 24 August 2010
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.
Subscribe to:
Posts (Atom)