arludwig commented 4 years ago

When I converted a set of characters (0x20 to 0xFF) from CP1252 to source code, the question mark inside the filled diamond also got assiged the number 0x3f (regular question mark), where it should have gotten number 0x81. (My font was Arial size 9.)

When I exported with character sorting, the regular question mark got replaced with the diamond one. When I exported without sorting, Arial09_0x3f and image_data_Arial09_0x3 got created twice, once for each variant of the question mark.

#if (0x0 == 0x0)
  // character: '?'
  {0x3f, &Arial09_0x3f},
#else
  // character: '?' == ''
  {0x3f, &Arial09_0x},
#endif

#if (0x0 == 0x0)
  // character: '�'
  {0x3f, &Arial09_0x3f},
#else
  // character: '�' == ''
  {0x3f, &Arial09_0x},
#endif

My settings:

* generated by lcd-image-converter rev.030b30d from [...]
[...]
* name: Arial09
* family: Arial
* size: 9
* style: Standard
* included characters:  !"#$%&'()*+,-./0123456789:;<=>?\x0040ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x007f€�‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ\x00a0¡¢£¤¥¦§¨©ª«¬\x00ad®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
* antialiasing: no
* type: proportional
* encoding: windows-1252
* unicode bom: no
*
* preset name: Monochrome
* data block size: 8 bit(s), uint8_t
* RLE compression enabled: no
* conversion type: Monochrome, Diffuse Dither 128
* split to rows: yes
* bits per pixel: 1
*
* preprocess:
*  main scan direction: top_to_bottom
*  line scan direction: forward
*  inverse: no

EDIT: added revision info to header extract

riuson commented 4 years ago

Character 0x81 is missing in encoding CP1252.

In revision e5ae407, a partial workaround for this problem is added, as well as an optional skip of such characters when converting to a font file.

Ramzess-II commented 11 months ago

скажите для чего вот эта обвертка везде?

riuson / lcd-image-converter

codepage 1252 missplaces question mark on conversion #50

if (0x0 == 0x0)

endif