diff --git a/LCD-Language.md b/LCD-Language.md index efda561..37ef6ea 100644 --- a/LCD-Language.md +++ b/LCD-Language.md @@ -93,8 +93,8 @@ On a 'perfect' system like Windows or Linux we'd dig out `unifont.ttf` and some - Make three fonts to simulate the HD44780 charsets on dogm-displays. With this fonts the translator can check how his translation will look on the character based displays. - Make ISO fonts for Cyrillic and Katakana because they do not need a mapping table and are faster to deal with and have a better charset (less compromises) than the HD44780 fonts. - Make mapping functions and tables to convert from UTF8 to the fonts and integrate in the new output functions. (`utf_mapper.h`) -- Delete the obsolete `LiquidCrystalRus.xxx` files and their calls in 'ultralcd_implementation_hitachi_HD44780.h'. -- 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`) +- Delete the obsolete `LiquidCrystalRus.xxx` files and their calls in '`ultralcd_implementation_hitachi_HD44780.h`'. +- 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`) - Do a bit of preprocessor magic to match displays - fonts and mappers in `utf_mapper.h`. ## Translators handbook @@ -126,16 +126,16 @@ If you get a lot of question marks on the Hitachi-based displays with your new t - `MAPPER_NON` is the fastest and least memory-hungry variant. - Mappers together with a ISO10646_font are the second-best choice regarding speed and memory consumption. Only a few more decisions are made per-character. - Mappers together with the HD44780_fonts use about additional 128 bytes for the mapping_table. -- Creating a new language file is not a big thing. Just make a new file with the format 'language_xx.h' or maybe 'language.xx.utf8.h', define a mapper and a font in there and translate some of the strings defined in language_en.h. You can drop the surrounding #ifndef #endif. You don't have to translate all the stings - the missing one will be added by language_en.h - in English - of cause. -- If you can't find a matching mapper things will be a bit more complex. With the Hitachi-based displays you won't have big chance to make something useful unless you have one with a matching charset. For a full graphic display - lets take the example of Greek: +- Creating a new language file is not a big thing. Just make a new file with the format '`language_xx.h`' or maybe '`language.xx.utf8.h`', define a mapper and a font in there and translate some of the strings defined in `language_en.h`. You can drop the surrounding `#ifndef` `#endif`. You don't have to translate all the strings - the missing one will be added by `language_en.h` - in English - of course. +- If you can't find a matching mapper things will be a bit more complex. With the Hitachi-based displays you won't have be able to make something useful unless you have one with a matching charset. For a full graphic display - lets take the example of Greek: - Find a matching charset. ([Greek and Coptic](http://en.wikipedia.org/wiki/Greek_and_Coptic)) - Provide a font containing the symbols in the right size. Normal ASCII in the lower 127 places, the upper with your selection. - - Write a mapper that catches -in this case- 0xCD to 0xCF and add it to `utf_mapper.h`. + - Write a mapper that catches -in this case- `0xCD` to `0xCF` and add it to `utf_mapper.h`. - In case of a ISO10646 font we have a `MAPPER_ONE_TO_ONE` and don't have to make a table. - - 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. - - If you want to integrate an entirely new variant of a Hitachi based display. Add it to `Configuration.h`. Define mapper tables in `utf_mapper.h`. Maybe you need a new mapper function. + - 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. + - If you want to integrate an entirely new variant of a Hitachi-based display. Add it to `Configuration.h` and define mapper tables in `utf_mapper.h`. You may need to add a new mapper function. -The length of the strings is limited. '17 chararacters' was a crude rule of thumb. Obviously 17 is too long for the 16x2 displays. A more exact rule would be `max_strlen = Displaywidth - 2 - strlen(value to display behind)`. This is a bit complicated. So try and count is my rule of thumb. +The length of the strings is limited. "17 chararacters" was a crude rule of thumb. Obviously 17 is too long for the 16x2 displays. A more exact rule would be `max_strlen = LCD_WIDTH - 2 - strlen(edit_value)`. This is a bit complicated. So try and count is my rule of thumb. On the 16x2 displays the strings are cut at the end to fit on the display. So it's a good idea to make them differ early. ('`Someverylongoptionname x`' -> '`x Somverylongoptionname`') @@ -149,9 +149,9 @@ Define your hardware and the desired language in `Configuration.h`. To find out what 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 "バパヒビピフブプヘベペホボポマミ" -- `WESTERN` displays "ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß" -- `CYRILLIC` displays "РСТУФХЦЧШЩЪЫЬЭЮЯ" +- `JAPANESE` displays "`バパヒビピフブプヘベペホボポマミ`" +- `WESTERN` displays "`ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß`" +- `CYRILLIC` displays "`РСТУФХЦЧШЩЪЫЬЭЮЯ`" If you get an error message about "missing mappers" during compilation - lie about your display's hardware font to see at least some garbage, or select another language.