Board.KolibriOS.org

Так речь же идёт не только о сглаживании курсива, речь идёт о масштабировании вообще. В идеале, шрифт должен быть контрастным, например чёрные символы на белом фоне и никаких других цветов. Но это возможно только при огромном разрешении монитора. На практике производится масштабирование больших символов с использованием либо обычного сглаживания полутонами (но это выглядит мыльно), либо ClearType (но это требует указаных условий). Собственно, ClearType работает так: векторные символы рисуются с трёхкратным горизонтальным разрешением, потом производится хинтинг по вертикали, и в конце субпиксели рассчитываются с учётом соответствующего пикселя и его соседей с соотношением, например 1-2-3-2-1, то-есть производится размытие цветов.
Там где курсив, я беру символы х6, потом обычное масштабирование по вертикали в 3 раза, потом ClearType, и никаких проблем здесь быть не дожно, если условия соблюдаются.
В последнем изображении я использую символы х5, х4 и х2. Здесь есть вертикальное размытие, из-за отсутствия хинтинга, но по горизонтали должно быть чётко.
В самом первом изображении я масштабировал х5 до х1,5 и действительно вижу некоторое размытие, что странно... Также, сделал разные соотношения: 1-2-3-2-1, 1-2-2-2-1, 5-6-5; разницы вроде нет.

Я сделаль. Библиотека экспортирует две функции. Первая считает количество символов в UTF8Z строке. Вторая рисует текст на 24-битном изображении, размер шрифта произвольный по вертикали и горизонтали, поддерживается жирный, курсив, подчёркнутый, перечёркнутый и полупрозрачность.

The program has been tested and works.
A screenshot with a typical english pangram:
Comments:
- "Number of characters" as an input to the function - a good idea.
- Alpha channel support for font color - I don't see the point of it. (But if it can be implemented at minimal cost, so be it.)
- Parameters: Input of width and height of the font is just weird. Ideally, I just want to input the em height of the font, and let the library worry about it.
- Size/speed: It seems the library has traded speed for size by using the kernel's internal font. The performance still seems acceptable at this point. (Perhaps at a later time, the system font can be placed in a shared read-only memory by the kernel, so that the library can work directly with the font data.)
- CountUTF8Z function - It's not what I wanted What I really need is a function that will tell me the width (and height) in pixels of a piece of text, so that I know if it will fit where I want to put it.
- The library does not take into account the width of the canvas (as seen on the screenshot) - This is not a problem for me, it might even improve the performance of the library a bit.

Char width may be useful if you want to fit the string onto image, but now you can input 0 for auto width.
About speed. Notice, that sysfunction 4 is optimized for fast draw to the buffer. Also, notice the scope of calculation bacchanalia in the library itself. Especially after I have added the stringWidth function.

Добавил выравнивание по центру или справа с учётом указаной координаты Х (или двух). Сделал автоматическое сужение строки, если она не вписывается в изображение или указаную область. Функция возвращает итоговые ширину символа и координату начала текста.

Pathoswithin wrote:Добавил выравнивание по центру или справа с учётом указаной координаты Х (или двух). Сделал автоматическое сужение строки, если она не вписывается в изображение или указаную область. Функция возвращает итоговые ширину символа и координату начала текста.

As much as I appreciate your initiative, this is useless for browser.
End of text is not essentially the same as width of canvas.

Also, I still have to process all UTF8 bytes manually to count characters, when not using UTF8Z string.
As mentioned before in another thread, it makes more sense to provide the number of bytes in buffer rather then number of characters (especially when invalid characters are involved.)

Yes, this will not help with multiline or sharing string between two canvases, but in other cases 01000000 flag should do the trick. I think, this may be useful for fullwindow canvas.
Should I add UTF8 character count by bytes? Or maybe, till some key char?

Currently, the idea of browser is roughly as follows:
- Parser creates something which looks like DOM tree (https://en.wikipedia.org/wiki/Document_Object_Model).
- Pre-renderer calculates page width (at least width of the window, but for example a very wide image can cause the page width to increase.)
- Pre-renderer calculates position of all objects and stores them in DOM tree.
- Renderer renders (at least) visible part of the page in the off-screen buffer
- The visible section of page is drawn (from off-screen) buffer to the window.

All text between two tags is essentially one object. This text may begin for example in the middle of the screen, and continue on the next line at another position.
My idea here is to let pre-renderer decide what word will get what coordinates (and markup) and store these values in the text object.

Sounds like UTF16 is more convenient for separating a string to words. Anyway, should I add more character count options?

UTF8 is convenient because it is most used encoding on the web. Converting UTF8 to UTF16 sounds like a useless step.
BTW, I don't understand your reasoning about this, I'm not talking about 16bits, but characters separated by spaces...

And yes, I'd appreciate it if you would replace "character count" with "byte count".

Byte count? Do you mean count characters by number of bytes, or count bytes till specified symbol (0 or else)?

the first.

Добавил поддержку 32-битного изображения, рассчёт количества символов в UTF-8 строке по количеству байт и тщательную проверку битых символов.

А можно добавить еще функцию подсчета числа символов в строке, при заданных ширине а пикселях и высоте шрифта?

Добавил.
Залил код. Для использования осталось включить в сборку.