bit mapped fonts for lcd displays made in china

The ST7290 allows you to define up to four 16x16 bitmaps. These bitmaps can be shown in any 16-bit location in the DDRAM, occupying the place of two individual characters.

At startup, we can now load our bitmaps into one or more of the CGRAM locations. Let"s make outselves some Space Invader aliens!void load_custom_bitmaps() {

Marlin deals with a variety of different displays and needs to display a lot of different languages in different scripts on them, within their capabilities. The system described here solves some of the related problems that need to be overcome with in a limited environment.

HD44780 (and similar) with Western charset A02 HD44780 (Page 18). These are rare, but fairly useful for European languages. Also a limited number of Cyrillic symbols is available.

On all these displays you can define 8 custom symbols to display at once. In Marlin these characters are used on the Boot Screen, and on the Info Screen for the Bed Temp, Degree symbol, Thermometer, “FR” (feed-rate), Clock, and Progress Bar. On the SD Card listing screens some of these characters are re-used again for Up-level, Folder, and Refresh.

Graphical displays provide complete freedom to display whatever we want, so long as we provide a program for it. Currently we deal with 128x64 Pixel Displays and divide this area into ~5 Lines with ~22 columns. So we need monospace fonts with a bounding box of about 6x10. Until now we’ve been using a custom Marlin font similar to ISO10646-1 but with special symbols at the end, which made ‘ü’ and ‘ä’ inaccessible at 6x10 size.

All these languages (except English) normally use extended symbols not contained in US-ASCII. Even the English translation uses some Symbols not in US-ASCII (e.g., ‘\002’ for Thermometer, STR_h3 for ‘³’). In the code itself symbols may be used without taking into account the display they’re written on.

The upshot of all this is that on Western displays you’ll see a ‘~’ while on Cyrillic an “arrow coming from top - pointing to left” (which is quite the opposite of what the programmer wanted). The Germans want to use “ÄäÖöÜüß”, the Finnish at least “äö”. Other European languages want to see their accents too. For other scripts like Cyrillic, Japanese, Greek, Hebrew, … you have to find totally different symbol sets.

The Japanese translator dealt with two scripts, introducing a special font for Graphical Displays and making use of the Japanese extended character displays. Thus he ended up with two pretty unreadable language.h files full of ‘\xxx’ definitions. Other languages either tried to avoid words that included special symbols or just used the basic symbols without the accents, dots… whatever.

Make output functions that count the number of chars written and switch the font to Marlin symbols and back when needed. (ultralcd_impl_DOGM.h) (ultralcd_impl_HD44780.h)

Make three fonts to simulate the HD44780 charsets on dogm-displays. With these fonts the translator can check how the translation will look on character-based displays.

Make ISO fonts for Cyrillic and Katakana - because they don’t need a mapping table, are faster to deal with, and have a better charset than the HD44780 fonts. (Less compromise!)

Split ‘dogm_font_data_Marlin.h’ into separate fonts and delete. (+dogm_font_data_6x9_marlin.h, +dogm_font_data_Marlin_symbols.h, -dogm_font_data_Marlin.h)

If you make extensive use, your file will look like language_kana.h and your language file will only work on one of the displays (in this case DISPLAY_CHARSET_HD44780 == JAPANESE).

If you want to make use of more than a few symbols outside standard ASCII or want to improve the portability to more types of displays, use UTF-8 input. Which means defining another mapper.

UTF-8 input is used for mappers other than MAPPER_NON. With a mapper, instead of “\xe1” (JAPANESE) or STR_ae you can simply type “ä”. The “ä” expands to “\xc3\xa4”. “Я” expands to “\xd0\xaf” … “ホ” expands to “\xe3\x83\x9b” … etc.

The mapper_tables do their best to find a similar symbol in the HD44780fonts (for example, replacing small letters with the matching capital letters). But they may fail to find a match and will output a ‘?’. There are combinations of language and display which simply have no corresponding symbols - like Cyrillic on a Japanese display or _vice-versa. In those cases the compiler will throw an error.

In short: Choose a mapper that works with the symbols you want to use. Use only symbols matching the mapper. On Full Graphic Displays all symbols should be fine. Using the graphical display, you can test for bad substitutions or question-marks that would appear on character displays by defining SIMULATE_ROMFONT and trying the different variants.

If you get a lot of question marks on the Hitachi-based displays with your new translation, maybe creating an additional language file with the format language_xx_utf8.h is the way to go.

Mapper Notes As mentioned, MAPPER_NON is the fastest and least memory-hungry variant. While MAPPER_NON language files are ugly and tedious to maintain for non-Roman languages, for Roman languages it is trivial to make a MAPPER_NON file without any accents.

If there’s no existing mapper for your language then things get a bit more complex. With the Hitachi-based displays you can’t make something useful without a matching charset. For graphical display… let’s take the example of Greek: Find a matching charset. (Greek and Coptic)

Provide a bitmap font containing the symbols in the right size (5x9 to 6x10 recommended). Normal ASCII characters should occupy 1 to 127, and the upper 128 places should be populated with your special characters.

If you discover enough useful symbols in one of the HD44780 fonts you can provide a mapping table. For example WESTERN contains ‘alpha’, ‘beta’, ‘pi’, ‘Sigma’, ‘omega’ ‘My’ - which is not enough to make USEFUL table - I think.

The length of strings (for menu titles, edit labels, etc.) is limited. “17 characters” was a crude rule of thumb. Obviously 17 is too long for a 16x2 display. So, language files are free to check the LCD width and provide shorter strings in the following manner:

On 16x2 displays, strings suited to a 20x4 display will be chopped to fit. So if shorter string isn’t provided, at least make similar strings different early in the string. (‘Someverylongoptionname x’ -> ‘x Somverylongoptionname’)

All translatable strings are first declared in language_en.h and then language maintainers follow up by providing translations in their own languages. Marlin includes a script named findMissingTranslations.sh which list the strings needing translation for one or more languages.

Strings in language.h are for serial output, so don’t require any translation. Core error strings must always be in English to satisfy host protocols.

To find out which character set your hardware uses, set #define LCD_LANGUAGE test and compile Marlin. In the menu you’ll see two lines from the upper half of the character set: JAPANESE displays “バパヒビピフブプヘベペホボポマミ”

LCD_LANGUAGE: The LCD language and encoding to compile in. For example, pt-br_utf8 specifies Portuguese (Brazil) in UTF-8 format with a mapper. For a faster, lighter, but non-accented translation you might choose pt-br instead.

MAPPER_C2C3: This is a mapper set by some language files, and indicates that Marlin should use the mapper for Unicode pages C2 and C3. In this mapper, strings are converted from raw UTF-8 input to single ASCII characters from 0-127, and indexes from 0-127 within the combined two 64-glyph pages C2 and C3.

SIMULATE_ROMFONT: Languages can opt to use the HD44780 ROM font special characters on graphical display. This method can be used for accented Western, Katakana, and Cyrillic if they don’t supply their own fonts, or just for testing character-based mappers on a graphical display.

DISPLAY_CHARSET_ISO10646_1: To support a graphical display, a language file must specify either SIMULATE_ROMFONT or a display character set. This specific option selects the Western font for use on graphical display. Others include ISO10646_5, ISO10646_KANA, ISO10646_GREEK, ISO10646_CN, ISO10646_TR, and ISO10646_PL. If no character set is specified, Marlin assumes ISO10646_1.

MAPPER_ONE_TO_ONE: Most character sets on graphical displays (including SIMULATE_ROMFONT) map the character index directly to its position in the upper half of the font. This is possible for character sets that have only 2 contiguous pages of Unicode containing all the special characters. Other mappers use logic or a lookup table to locate the glyph.

Current incarnations might be available for large LED displays, but those may work best for point LEDs rather than square filled pixels, and ideally these would be something recognizable by some as having historical aspects.

The application is a small 128x64 pixel OLED display. I currently use Python"s PIL which has a "default" font that is just too small for this display. I can also use it to read TrueType fonts, then I down-convert to gray scale then use a threshold to get 1-bit, but it looks ragged. See here and here but here I"m not asking for Chinese characters; even the original ASCII would be helpful.

Example of a 1-bit binary OLED display (128x64 pixels) cropped from this image from the AdaFruit Page Monochrome 0.96" 128x64 OLED graphic display, Product ID: 326.

These days even black-and-white fonts are displayed using grayscale or even color. Zoomed screenshots from my laptop showing that what looks black-and-white isn"t. Trying to post-process these back to binary by thresholding can lead to rough edges and strange looking characters.

Sorry I’ve got an adblocker on, I didn’t realise it was a bad site. I can’t attach the files as this forum only allows JPG and PNG and GIF, but I can paste them here. I’ll include the .ino as well since that’s where the compiler error is pointing:

And sorry again for the long delay. I have revisited and rebased your code many times in hope that it would get more attention, but wow things have been piling up around here….

Currently I am working on the deluxe version of the data logger. This version has a LCD screen and capacitive buttons to control the software. The Adafruit library for the display is quite large and almost uses the whole RAM, because it is a pixel oriented library. My own implementation is a text only library using 8×8 pixel characters. This simplify everything and reduces the RAM costs.

To convert the bitmap font into bytes, I wrote a small application for OS X (minimum version 10.10). It accepts a PNG image with the characters in it and converts it into bytes with the correct bits set.

First you select the mode on the left side of the application window. In this example the mode is set to “8×8 Fixed Top-Down”. Select the output format in the bottom left corner of the window.

Here an example 8×8 pixel font file for the converter. The font converter ignores any transparent and light values. So you can use them on a second layer as a grid for the font.

You can use this font template for Adobe Photoshop if you plan to deign a own font. The template uses a grid on one layer, so you can draw the font information on the second layer.

The software is written in Swift 2 and is using many of the new features of this language. The code is extensible and you can easily add own converter and output formats. If you created useful additions, please let me know.

Here’s a neat little trick: take the jaggies out of scaled fonts on the fly! This technique is for use on graphic displays where you might want to scale your fonts up. Normally you’d just write a 2×2 block of pixels for every area where there would have been one pixel and boom, larger font. Problem is, that also multiplies each empty area and you end up with jagged edges in the transitions that really catch your eye.

The technique has been packaged up in a simple function that [David] wrote to play nicely in the Arduino ecosystem. However, the routine is straightforward and would be quick to implement no matter the language or controller. Keep this one in your back pocket!

Now if all you have on hand is an HD44780 character LCD, that one’s arguably even more fun to hack around on just because you’re so limited on going beyond the hard-coded font set. We’ve seen amazing things like using the custom character slots to play Tetris.

The 4.3inch e-Paper UART Module adopts a serial port, with a resolution of 800 × 600, built-in Chinese and English fonts, and low power consumption. If you don"t want to learn the complex details of the bottom of the e-paper screen and don"t pay attention to the specific display algorithms of graphics, text and pictures, then this product is born for you. Just one serial port can realize all functions, free you from complicated details and release your creativity.

When using an external TF card, you should format the TF card into a FAT32 system, and place the font libraries provided by Waveshare and the images you want to display to the external TF card before using it.

When using the internal NandFlash, you should import the font libraries and image files you want to display to the internal NandFlash in advance. For more detailed information, please refer to the Section 2.2.

The system built-in 32, 48 and 64 dots English font is always available without using the TF card or the NandFlash; however, for the 32, 48 and 64 dots Chinese font, you should store the relative library file to the TF card or the NandFlash before using it.

The system supports 1-bit and 2-bit bitmap image display. For other image formats, you should convert these images into the specified format with the tool on the Demos so as to display them.

Click File -> Save As, and select the option Windows Bitmap file(*.bmp)"in theSave as Type list, and then enter a correct file name and save the image. Please take note to the format of the file name.

We have designed the software for E-Paper to work with PC. With this software, users can easily operate different basic displays on the E-Paper via a PC. In additional, a USB-to-serial module should be applied to build up the communication between the e-Paper and the PC. In here, we will take the serial module CP2102 USB UART Board(mini) as an example to illustrate the application. For more detailed information about this serial module, please refer to Appendix.

Prepare a micro SD card (here we take an 8G micro SD card as an example), and format the micro SD card into a FAT32 system with 4096 bytes allocation unit size. Copy the font libraries and image files provided by Waveshare into the micro SD card. When finished, insert the micro SD card into the E-Paper.

Set the drawing color, the option Foreground color for the text is set to Black and the option Background color for the background is set to White by default;

[2] For drawing point(s) or line(s), or displaying text(s) or image(s), you should click the button Refresh to update the display on the E-Paper screen whenever you finish each drawing.

Here, we take Arduino UNO development board as an example to illustrate the application. Connect the development board to the e-Paper with a serial cable as shown in the follow table. For more information about this development board, please refer to the Appendix.

Here, we take NUCLEO-F103RBdevelopment board as an example to illustrate the application. Connect the development board to the e-Paper with a serial cable as shown in the follow table. For more information about this development board, please refer to the Appendix.

Here, we take Open103Z development board as an example to illustrate the application. Connect the development board to the e-Paper with a serial cable as shown in the follow table. For more information about this development board, please refer to the Appendix.

The data of the module is transmitted in the Network byte sequence, which means higher byte is sent at first, then lower byte following. For example, a parameter, 0x1234, is transmitted in two parts: 0x12 is sent at first, and then 0x34 following.

After powered up, the default Baud rate is 115200. This command is used to set the Baud rate. You may need to wait 100ms for the module to return the result after sending this command, since the host may take a period of time to change its Baud rate.

Set the foreground color and the background color on drawing, in which the foreground color can be used to display the basic drawings and text, while the background color is used to clear the screen.

Before executing this command, please make sure the bitmap file you want to display is stored in the storage area (either TF card or internal NandFlash).

The name of the bitmap file should be in uppercase English character(s). And the string length of the bitmap name should be less than 11 characters, in which the ending "0" is included. For example, PIC7.BMP and PIC789.BMP are correct bitmap names, while PIC7890.BMP is a wrong bitmap namem.

250 is an undefined error. It may be that the name of the picture entered is wrong when displaying the picture, pay attention to the capitalization, and if the TF card is pulled out, when the TF card is connected for the next time, it can be used normally after powering on again.

2. Please use independent power supply, do not use serial port module to supply power. Because the current required to refresh the screen is large, when using the serial port module for power supply, it may cause serial port problems or SD card problems. In this case, using the SD card will report an error: Error: 1, Error: 3, or Error: 4.

From Wikipedia:Computer font: "A computer font is implemented as a digital data file containing a set of graphically related glyphs. A computer font is designed and created using a font editor. A computer font specifically designed for the computer screen, and not for printing, is a screen font."

The typesetting application TeX and its companion font software, Metafont, traditionally renders characters using its own methods. Some file extensions used for fonts from these two programs are *pk, *gf, mf and vf. Modern versions can also use TrueType and OpenType fonts.

You should give pacman the ability to manage your fonts, which is done by creating an Arch package. These can also be shared with the community in the AUR. The packages to install fonts are particularly similar; see Font packaging guidelines.

The family name of a font file can be aquired with the use of fc-query for example: fc-query -f "%{family[0]}\n" /path/to/file. The formatting is described in

The recommended way of adding fonts that are not in the repositories of your system is described in #Creating a package. This gives pacman the ability to remove or update them at a later time.

The creation of a subdirectory structure is up to the user, and varies among Linux distributions. For clarity, it is good to keep each font in its own directory. Fontconfig will search its default paths recursively, ensuring nested files get picked up.

For the Xserver to load fonts directly (as opposed to the use of a font server), the directory for your newly added font must be added with a FontPath entry. This entry is located in the Files section of your Xorg configuration file (e.g. /etc/X11/xorg.conf or /etc/xorg.conf). See #Older applications for more detail.

With older applications that do not support fontconfig (e.g. GTK 1.x applications, and xfontsel) the index will need to be created in the font directory:

If you are seeing errors similar to this and/or seeing blocks instead of characters in your application then you need to add fonts and update the font cache. This example uses the

This is a selective list that includes many font packages from the AUR along with those in the official repositories. Fonts are tagged "Unicode" if they have wide Unicode support.

GNU FreeFont (URW Ghostscript fonts (e.g., Nimbus Roman, Nimbus Sans), non-Latin characters come from many sources with good Unicode coverage, but do not include CJK

Microsoft fonts (AUR) – Andalé Mono, Courier New, Arial, Arial Black, Comic Sans, Impact, Lucida Sans, Microsoft Sans Serif, Trebuchet, Verdana, Georgia, Times New Roman

Courier Prime (AUR) – Courier alternative which has been supplemented by a sans serif font and a version optimized for programming, released under the Open Font License.

Tahoma (Wine Replacement) (AUR) – Open source substitute for Tahoma developed by the Wine project. It was created because many Windows applications expected Tahoma to be available

Bitstream Charter (AUR, AUR) – Originally a commercial font designed by Matthew Carter. A version was released under a free license and later converted to modern formats (provided as the aforementioned packages).

AUR – A huge collection of free fonts (including Ubuntu, Inconsolata, Roboto, etc.) - Note: Your font dialog might get very long as >100 fonts will be added.

Adobe Source Han fonts and Noto CJK fonts have identical glyphs and metrics, but with different branding since the project was commissioned by both Adobe and Google.

Almost all Unicode fonts contain the Greek character set (polytonic included). Some additional font packages, which might not contain the complete Unicode set but utilize high quality Greek (and Latin, of course) typefaces are:

Emojis should work without any configuration once you have at least one emoji font installed of supported format. Emoji font fallback according to the standard requires extra code to handle emoji.

Kaomoji are sometimes referred to as "Japanese emoticons" and are composed of characters from various character sets, including CJK and Indic fonts. For example, the following set of packages covers most of existing kaomoji:

STIX fonts (AUR) – STIX is designed to be a royalty-free alternative that resembles Times New Roman. The current version is called STIX Two and includes a math companion named STIX Two Math.

XITS fonts (AUR) – A fork of STIX and therefore resembles Times New Roman. XITS includes a math companion called XITS Math, which has similar levels of completeness for mathematical symbols and alphabets when compared to STIX Two Math [6], although there are some visual differences.

Fontconfig automatically chooses a font that matches the current requirement. That is to say, if one is looking at a window containing English and Chinese for example, it will switch to another font for the Chinese text if the default one does not support it.

There are several font aliases which represent other fonts in order that applications may use similar fonts. The most common aliases are: serif for a font of the serif type (e.g. DejaVu Serif); sans-serif for a font of the sans-serif type (e.g. DejaVu Sans); and monospace for a monospaced font (e.g. DejaVu Sans Mono). However, the fonts which these aliases represent may vary and the relationship is often not shown in font management tools, such as those found in KDE and other desktop environments.

Applications and browsers select and display fonts depending upon fontconfig preferences and available font glyph for Unicode text. To list installed fonts for a particular language, issue a command fc-list :lang="two letter language code". For instance, to list installed Arabic fonts or fonts supporting Arabic glyph:

For terminal emulators that use X resources, e.g. xterm or rxvt-unicode, fonts can be set by using escape sequences. Specifically, echo -e "\033]710;$font\007" to change the normal font (*font in ~/.Xresources), and replace 710 with 711, 712, and 713 to change the *boldFont, *italicFont, and *boldItalicFont, respectively.

Matplotlib (~/.matplotlib/fontList.cache, ~/.cache/matplotlib/fontList.cache, ~/.sage/matplotlib-1.2.1/fontList.cache, etc. so it will regenerate its cache and find the new fonts [7].

I had already forgotten the details of this library. But as it uses Adafruit_GFX, you can use all fonts available with Adafruit_GFX with it, and Adafruit_GFX even has a font creation tool (I don"t know).

If you want to add fonts compatible to Adafruit_GFX, you add the font files to the Fonts directory of Adafruit_GFX, or to a Fonts directory added to the src directory of the SSD1283A library.

Please forget the header of the example. I had used a copy of an example from Bodmer, which is a copy of an Adafruit_GFX example, which obliged me to keep this header note.

I have started to speed up the lib with using DMA and direct SPI programming. To do this I have to split the code for the different platforms. To prevent unreadable code with a lot of #ifdef... I have create a new file. The #ifdef definition around is switching between the platforms.

Unfortunately this adapter is set to 9 bit SPI mode via the mode pins IM0-IM3. If you want to patch this - like I have done - you have to desolder the TFT from the pcb to cut some traces. This is a flexible print. Only for people with soldering skills !

You also have to get access to pin 36 for the dc signal. Cut the GND connection. You can use the level converter used for the LCD_LED signal. Mosfet Q1 can be driven with a logic signal without converter. Watterott will change this in a future revision.

To print characters to a graphic screen we need a font. To code a font by paper is ok for a small lcd, but for a 320*240 pixel display we need bigger fonts. A 12*12 pixel font is readable, but a lot of work to construct.

Load from mbed flash. It consume a lot of flash memory. To construct a bitmap array we can use gimp. http://www.gimp.org/ Load a image (edit and resize) and export it as BMP. You have to select the option 16 bit R5 G6 B5 !

simply copy test.bmp to the mbed usb drive or the SD-card. The bmp has to be saved with the options 16 bit R5 G6 B5 ! You can use the program gimp to convert pictures into the 16 bit bmp format.

This one has some rather exotic video hardware, but also offers a basic 80x25 text mode with a distinct, (mostly) sans-serif 9x14 font. Unlike most PC hardware fonts, the 9th column is stored in the actual bitmap data.

Mostly based on CGA, the Convertible adds support for redefinable 8x8 charsets. The default is a rather elaborate serif font, which IBM also used as a basis for PC-DOS 3.20"s LCD-specific codepages.

The squat, built-in monochrome LCD had square pixels at 640x200 (that"s 16:5 - how"s that for you widescreen fanatics?), but the optional external monitor was a regular 4:3 CRT, so the aspect-corrected versions are based on that.

In the earliest variant of the PS/2 Model 30 (the "rev. 0" BIOS dated 09/02/86), the built-in 8x16 font is slightly different from the MCGA/VGA font of the later units: "0", "O", "ß", and characters with descenders and umlauts are closer to their EGA forms. The Model 30 is MCGA-only, so there is no 9-dot-wide version.

PS/2 models based on the 16-bit ISA bus (at least the 25-286, 30-286, 25 SX, 35 SX) include additional fonts in ROM, alongside the usual VGA fonts. These are all rather nondescript, and I"m not aware of any software that ever actually used them; they"re not documented and the video BIOS code doesn"t seem to reference them, so such software is unlikely to exist.

The PS/2"s Japanese cousin had generously large bitmap fonts to support that language"s various scripts. Since full CJK fonts are outside the scope of this collection, the version here is a CUSTOM REMAPPING to CP437 (with supplements).

Internally the bitmaps are 12x24 dots. Later, they were replicated in IBM DOS/V for generic PCs; at least the half-width Latin alphanumerics appear to be exactly the same, so this version is almost identical to the "JP-24" font in the DOS/V section. Almost, but not quite: the PS/55"s display adapter padded the characters to 13x29, so this font follows suit.Font/CharsetsAspectSample

These are a bit of an exception here, since they"re not really hardware fonts. IBM"s more advanced PC video standards had, among other things, hardware-accelerated text output for their high-resolution graphics modes. These were accessed with an API called simply the Adapter Interface ("AI"), and the AI drivers for DOS contained some fonts for this purpose. (There"s also an 8x14 size, but it basically copies the EGA/VGA font.)

True text modes remained purely a VGA function, although XGA(-2) had integrated the VGA part into the chipset, so they still used the same fonts as VGA.

Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

So we answer the question with another question. What do you respect more: the pixel grid, or the font designer? It"s not surprising that Apple would side with the font designer, because Steve Jobs thinks Microsoft has no taste. But me, I"m a pragmatist. Given the ubiquity of relatively low DPI displays, I"m with Dave Shea. I side with the pixel grid.

And that"s the difference here. ClearType is a closer match to what I do manually already. Yes, I prefer the way type on OS X looks; ClearType seems too sharp and overly blocky, the subtleties of the curves are lost and it"s overly chunky. But, for the medium in which it"s being rendered, it seems like a more ideal solution.

Dave"s opinion carries a lot of weight here, not just because he"s a well-known designer, but because the three citations he provides demonstrate just how common it is for designers to do exactly the kind of manual, per-pixel tweaks that ClearType does for us automatically. And it"s not just an aesthetic choice, either – there"s plenty of hard data to support the assertion that snapping fonts to the pixel grid improves reading accuracy.

A fascinating greyscale-only variant of this rendering techique, FontFocus, illustrates beautifully how subtle tweaks can "snap" fonts to the pixel grid for better readability:

Dave Shea thinks the pixel grid will be moot once high resolution displays become ubiquitious. I wholeheartedly agree, although I"m unsure when exactly that will be. The history of display resolution increases have been quite modest so far. Ten years ago I was using a single 17" 1024x768 display; now I"m using three 20" 1600x1200 displays. So you"ll forgive me if I"m not overly optimistic about this theoretical jump from 100 DPI to 200 DPI.

I don"t understand why Apple is asking us to sacrifice the present at the altar of the future. Can"t we have hinting at low resolutions, and accuracy at high resolutions, too? Snapping fonts to a pixel grid may very well be irrelevant when everyone is luxuriating in the glow of their 200 DPI monitors. Until that glorious day arrives, respecting the pixel grid certainly makes text a lot more readable for those of us stuck in the here and now.