Utils review/revisit

[puzrin]

I try to understand, how to automate things. For example - rebuild fonts after translations update, language add or fontface change. Usually all commands are stored in makefile (or anything else).

When i see this repo content, my thougts are:

• 3 different languages????
• php is certaintly NOT thing i wish to install :). And glued params with & - not what i expect from CLI tool.

I could try to rewrite everything "right" with nodejs/browser, but will not maintain this forever. Could you explain me your requirements and expectations?

• Is is acceptable to use JS for CLI (node.js)? (some people not like it, and python is already installed in most linux systems)
• How critical is to have easy install for native windows CLI? node-canvas is so-so there... But:
  • Last windows seems to have embedded ubuntu in console (don't know details)
  • Web version not affected
• Do you have some not implemented but very liked features?

As a nice bonus: web version will not require server side scripts at all.

[kisvegabor]

The PHP scripts are really not user friendly. I didn't plan to share them once there are online converters but it turned out the offline converters are required too. People use them to automate things and to simply re-generate a lot of files.

I'd prefer JS over Python to make possible to run the same scripts in the browser. With Python two script needs to be maintained in two languages.

I think node.js is fine for offline usage. It's so popular now that nobody will complain about why node.js need to used. We can even upload it to npm.

Actually, there is one think what I was planning to add. It's called kerning. I imagined it like having a file with similar content:

W A -2  
W . -3

which means apply -2 letter space if W is followed by A.
In C it means an array which pointer is also registered in lv_font_t.

Do you plane to add GUI too or creaeting "only" the CLI tool?

[puzrin]

Do you plane to add GUI too or creaeting "only" the CLI tool?

I usually do both, but browser pages are very minimalistic.

[kisvegabor]

I usually do both, but browser pages are very minimalistic.

A similar look and feel should be fine like to current one.

[puzrin]

One more question. Did you inspected u8g2 fonts format? It's a bit more compact, but more cryptic. I don't care about size, but like to understand why you did not used existing one.

[kisvegabor]

I didn't check u8g2 in details until now. I saw a good idea in it: don't store all rows of data i.e. crop the empty top and bottom parts. It requires only 2 bytes per glyph (y1, 2) but save a lot. E.g. here half of the glyph is empty:

    0x00,  //........
    0x00,  //........
    0x00,  //........
    0x00,  //........
    0x00,  //........
    0x00,  //........
    0x3c,  //.+%@@@+.
    0x7e,  //.@@@@@@.
    0x47,  //.%...%@%
    0x03,  //......@@
    0x3f,  //.+@@@@@@
    0xff,  //%@@@@@@@
    0xc3,  //@@+...@@
    0xc7,  //@@+..%@@
    0xff,  //%@@@@%@@
    0x7b,  //.%@@%.@@
    0x00,  //........
    0x00,  //........
    0x00,  //........
    0x00,  //........

I didn't consider using external a library for this purpose because:

1. Font handling has evloved continously and the next step was always starigtforward
2. For a core feature like this it's good to have full controll over it. A custom implementation will fit better into lvgl than an external library.

[puzrin]

Ok. I think custom format is not a big issue. All we need is convenient convertor, easy to use. If it's available, any internal improvments can be done later, transparent to user.

[kisvegabor]

I agree. So do you really planning to rewrite the php scripts in JS?

[puzrin]

That should not take a lot of time, but i'd like to understand all "missed features" before. I mean, i18n issue. Rewriting php->js as standalone task will "coding just for fun". But solving i18n will be a useful thing for my projects. I this scope, improving existing convertor will be essential part.

[kisvegabor]

Ok, Let's postpone it until i18n is established.

[puzrin]

I find a bit strange to keep assorted tools in one repo. But until better alternative available - created a separate issue about font builder.

May be worth create separate repo for TTF convertor, separate repo for image convertor, and RIP the rest?

[kisvegabor]

I'm ok with two repo for the two tools. This repo can be left for specific utilities from users such as the BDF converter for pixel-perfect fonts.

[puzrin]

Are those BDF fonts not available in TTF format?

[embeddedt]

@puzrin Some of them may be that way. From my experience BDF and TTF are used in different areas.

[puzrin]

@embeddedt this may be caused by lack of proper tools, not by unique BDF features.

I know some big BDF collections, but very sceptic about those quality.

[kisvegabor]

Anyway, I see no problem with having a repo for small tools to solve specific problems.

[puzrin]

I try to understand, what should be "modernised" from this repo, after i18n & font generator done. Because first impression of assorded scripts and languages is "not optimistic" :).

[kisvegabor]

I think it's not a critical thing. We can have a dedicated folder for assorted tools. Or as you sugested we can add font and image converters to separate repos, resulting 3 repos:

1. assorted tools
2. image converter
3. font converter

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kisvegabor]

To close this conversation, let's use the structure I described above:

1. assorted tools
2. image converter
3. font converter

@puzrin I'll open new repos for the image and font converters and give write access to you.