Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

codepage 1252 missplaces question mark on conversion #50

Open
arludwig opened this issue Jan 31, 2020 · 2 comments
Open

codepage 1252 missplaces question mark on conversion #50

arludwig opened this issue Jan 31, 2020 · 2 comments
Assignees
Labels

Comments

@arludwig
Copy link

arludwig commented Jan 31, 2020

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 riuson self-assigned this Apr 5, 2020
@riuson
Copy link
Owner

riuson commented Apr 5, 2020

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.

@riuson riuson added the bug label Apr 5, 2020
@Ramzess-II
Copy link

скажите для чего вот эта обвертка везде?
#if (0x0 == 0x0)
#endif

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants