Библиотека масштабируемых шрифтов для Колибри

Discussing libraries simplifying applications development
  • Потом для изменения придется переписывать все используемые приложения и терять совместимость если не переписывать...

    З.Ы. Форум работает в режиме чата... почти.
  • Mario, ну чат ведь убрали...

    Sorcerer, да

    Mario, форкнуть, будет лучше - перейдут, хуже (или недостаточно лучше) не перейдут...

    Впрочем, обсудить реально надо. У меня, в свою очередь, особых пожеланий нет пока... Ведь даже черновика нет - сложно судить(
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Если есть необходимость, можно перенести обсуждение в IRC, а затем особенно умные мысли опубликовать тут, чтобы с ними могли ознакомиться те, у кого IRC нет, или те, кого нет в сети.

    Библиотека однозначно будет уметь выводить текст в область памяти, считать длину и высоту текста в пикселах. Возможно она должна будет уметь сама выводить текст в окно, и может быть поддерживать форматирование текста и расширенные атрибуты (хотя мне кажется, что этим должна заниматься конечная программа, а не библиотека шрифтов).
  • XVilka wrote:Взять подмножество функций из http://freetype.sourceforge.net/freetyp ... 2-toc.html ?
    Мне кажется, функции freetype сильно заточены под freetype. Например, типы данных. Нафига столько?
    FT_Byte FT_Offset FT_UnitVector
    FT_Bytes FT_PtrDist FT_F26Dot6
    FT_Char FT_String FT_Pixel_Mode
    FT_Int FT_Tag ft_pixel_mode_xxx
    FT_UInt FT_Error FT_Palette_Mode
    FT_Int16 FT_Fixed FT_Bitmap
    FT_UInt16 FT_Pointer FT_IMAGE_TAG
    FT_Int32 FT_Pos FT_Glyph_Format
    FT_UInt32 FT_Vector ft_glyph_format_xxx
    FT_Short FT_BBox FT_Data
    FT_UShort FT_Matrix FT_Generic_Finalizer
    FT_Long FT_FWord FT_Generic
    FT_ULong FT_UFWord FT_MAKE_TAG
    FT_Bool FT_F2Dot14
    А ведь эти типы использует большая часть из функций (базовых, так сказать):
    FT_Library FT_IS_TRICKY FT_Load_Char
    FT_Face FT_STYLE_FLAG_XXX FT_LOAD_XXX
    FT_Size FT_Size_Internal FT_LOAD_TARGET_XXX
    FT_GlyphSlot FT_Size_Metrics FT_LOAD_TARGET_MODE
    FT_CharMap FT_SizeRec FT_Set_Transform
    FT_Encoding FT_SubGlyph FT_Render_Mode
    FT_Glyph_Metrics FT_Slot_Internal ft_render_mode_xxx
    FT_Bitmap_Size FT_GlyphSlotRec FT_Render_Glyph
    FT_Module FT_Init_FreeType FT_Kerning_Mode
    FT_Driver FT_Done_FreeType ft_kerning_default
    FT_Renderer FT_OPEN_XXX ft_kerning_unfitted
    FT_ENC_TAG FT_Parameter ft_kerning_unscaled
    ft_encoding_xxx FT_Open_Args FT_Get_Kerning
    FT_CharMapRec FT_New_Face FT_Get_Track_Kerning
    FT_Face_Internal FT_New_Memory_Face FT_Get_Glyph_Name
    FT_FaceRec FT_Open_Face FT_Get_Postscript_Name
    FT_FACE_FLAG_XXX FT_Attach_File FT_Select_Charmap
    FT_HAS_HORIZONTAL FT_Attach_Stream FT_Set_Charmap
    FT_HAS_VERTICAL FT_Reference_Face FT_Get_Charmap_Index
    FT_HAS_KERNING FT_Done_Face FT_Get_Char_Index
    FT_IS_SCALABLE FT_Select_Size FT_Get_First_Char
    FT_IS_SFNT FT_Size_Request_Type FT_Get_Next_Char
    FT_IS_FIXED_WIDTH FT_Size_RequestRec FT_Get_Name_Index
    FT_HAS_FIXED_SIZES FT_Size_Request FT_SUBGLYPH_FLAG_XXX
    FT_HAS_FAST_GLYPHS FT_Request_Size FT_Get_SubGlyph_Info
    FT_HAS_GLYPH_NAMES FT_Set_Char_Size FT_FSTYPE_XXX
    FT_HAS_MULTIPLE_MASTERS FT_Set_Pixel_Sizes FT_Get_FSType_Flags
    FT_IS_CID_KEYED FT_Load_Glyph
    То есть делать подмножество freetype не выйдет - передаваемые функциям параметры вряд ли совпадут. Нужны свои функции, пусть и аналогичные фритайповским. Мне например нравится их идея с CharMap, Metrics, Encoding...
  • Я думаю для библиотеки нужно уметь выводить строку символов и возвращать приложению результат сколько символов влезло, если они все не поместились в выводимую область для строки. Для пущей важности можно выводить множество строк, но тут уже не совсем понятно как слова переносить. Заставлять выводить приложение каждый символ неэффективно в плане производительности, хотя можно оставить такой вариант для реализации разнообразных эффектов.
  • Выводить множество строк, впрочем, рационально с точки зрения производительности. Меньше лишних телодвижений, один битмап на выходе, к примеру.
  • Mario, если библиотека может считать размеры строки относительно точки, от которой рисуется строка (вниз, влево, вправо, вврех), без рисования, то она должна это позволять.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • пусть переносом занимается тогда приложение. а при выводе множества строк обрабатывать символ переноса строки.
  • XVilka, приложение заранее не может знать, сколько пикселов занимает строка вширь, так что не может расставить символы перевода строки самостоятельно
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Приложение может спросить об этом у библиотеки. Даже для строки в 80 символов длиной сложить 80 чисел - не так уж и сложно. Обработка символа переноса строки - зачетная идея. \r\n или еще что использовать в качестве этого?
  • \n хватит. Или кто-то еще переводит каретку?


    Sorcerer: "Приложение может спросить об этом у библиотеки."
    алгоритм приложения работы.
    надо вывести строку длиной в рамку шириной икс.

    togoto:
    -Библиотека, скажи ширину этой строки длиной 1!
    -Библиотека, скажи ширину этой строки длиной 2!
    -Библиотека, скажи ширину этой строки длиной 3!
    ....
    -Библиотека, скажи ширину этой строки длиной n-1!
    -Библиотека, скажи ширину этой строки длиной n!
    ^пока возвращаемая ширина y не станет y >= x.
    Если стала, переносим все символы, следующие за символом (k - сколько строк уже выведено) k*x+y на 1 символ
    [тут переносится 65кбайт (например), строка байт на 1 байт вправо: бввввдыщщщщч], в освободившийся байт записываем \r
    k++
    goto togoto

    так?
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Можно и так:
    Библиотека_Скажи_Сколько_Букв_Влезет_В_Битмап(Строка, Ширина_Битмапа, Высота_Битмапа)
  • параметры шрифта тоже надо указывать при вычислении.
  • Само собой.

    Для ускорения работы на небольших размерах предлагаю загружать файл шрифта в память и растрировать в нужном размере, а потом хранить глифы как битмапы, и по надобности собирать из них готовые изображения. Для больших кеглей такой метод не прокатит - вряд ли будет быстрее, зато памяти много потребуется. Хотя, это нужно пробовать.
  • Who is online

    Users browsing this forum: No registered users and 5 guests