Board.KolibriOS.org

<Lrz> wrote:По дефолту получить тип шрифта то же можно, но где-то должна храниться информация о настройках - есть предложения?

может стоит добавить какойнить system.ini... и там хранить настройки???
можно туда прописать пути к либам... и другие системные настройки... а так же можно туда запихать все ассоциации.... например, jpeg=imgview.... txt=notepad... и разные проги смогут юзать единсвенный ini файл... а не создавать свой....

Если там собрать информацию о всей системе, то это будет оч огромный ini файл.
Можно сделать простую либу, которая будет получать информацию из такого файла

Я думаю с битовыми шрифтами не стоит увеличивать энтропию и создавать заголовки. К тому же это усложнить задачу включения существующих (а у меня их есть, но нет желания париться с заголовками) шрифтов. Имя и размер легко вычленяются из имени файла. Просто, обязательным условием для именования таких шрифтов станет указание размера, например: arial_8x8.fnt, arial_8x12.fnt, arial_8x16.fnt и т.д. При создании экземпляра шрифта (font_load или по твоей схеме get_font) указывается только имя, в этот момент сканируется директория (или ряд директорий) со шрифтами и выбираются соответствующие указанной выше маске. После указания размера шрифта (font_set_size) из подготовленного множества шрифтов выбирается наиболее подходящий.
На первых парах этого будет достаточно. Со временем можно внести и всякие system.ini (пока я не вижу в этом необходимости) или другие форматы с метаданными, в которых более подробно и точно будут описаны те или иные шрифты (кодировка, язык, набор символов, размеры, типы и т.д. и т.п.).

..bw

bw
Плохая идея не иметь заголовков т.к. если у тебя есть шрифты в raw формате сделать для них заголовок - дело 2-х минут. Представь, что ты закинул в папку шрифтов файл, который по названию оч похож на arial_8x12.fnt, без проверки заголовка, не возможно сказать, что это нужный файл, именно тот с которым будет работать система, если у него битность !=1, то такой файл как минимум не будет выведен, в другом случае не представляю, что еще может произойти. Еще, появились шрифты другого формата, меняешь заголовок типа и настраиваешь либу для их обработки. В случае если информация представлена только в имени файла это будет сложнее сделать. Еще пользователь может подсунуть не корректный файл, поменяв ему расширение и т.д. и т.п.
Проверка расширения, а потом и заголовка, хоть и не много утомительна, но все же больше страхует от таких действий. Я все же надеюсь, что библиотека со временем научиться работать с другими типами шрифтов.

> Представь, что ты закинул в папку шрифтов файл, который по названию оч похож на arial_8x12.fnt
Ну дурак, если закинул. Сам же за это и отвечу. Давай тогда еще и CRC32 сделаем. В маразм просто тоже впадать не стоит.
Я предложил, как мне кажется, очень простой и удобный вариант. Без дополнительного утиля, без hex-редакторов, можно будет простым копированием и переименовыванием добавлять в систему шрифты. А если пользователь закосячил, то вместо текста у него в программах будет месево. А вот если автор либы закосячил (например полностью пологаясь на заголовок), то приложения будут вылетать с непонятной ошибкой.

> Еще пользователь может подсунуть не корректный файл, поменяв ему расширение и т.д. и т.п.
Он так же и с заголовком может поступить. Повторюсь, если пользователь не отвечает за свои действия, то пусть идет этот пользователь... У меня исключительно такой подход к дуракам.

p.s. Делай как знаешь. Я твои агрументы не принимаю :-). Такой подход создаст больше неудобств чем увеличит защиту от дурака. Тем более KOS дураки пока не пользуются. Что касается последнего утверждения, а так же всех предыдущих это исключительно моё мнение.

..bw

Попрошу Serge, Ghost,diamond,mike.dld и других высказаться, если поддержите идею bw, сделаю отдельную функцию

Заголовок нужен. Я не понимаю любви к RAW формату, который подходит лишь для узкого применения. С другой стороны, согласен с тем, что хотелось бы загружать шрифт по имени и позже устанавливать размер (с чем будет сравниваться имя - с именем файла или же полем в заголовке файла - пока что не важно).

> Я не понимаю любви к RAW формату
Мне не нравится идея создания всё новых и новых форматов, на сколько бы примитивны они не были. Это информационный мусор. То что действительной необходимости в заголовке нет я показал, <Lzr> на этот счет имеет свои аргументы. Правда я считаю что их недостаточно и нежелание плодить очередной формат-выкидыш для меня является достаточным мотивом, что бы отказаться от заголовка. Но так как реализацией занимается <Lrz>, то мои жизненные принципы не имеют значения :-).

p.s. Это кажется ты, mike.dld, что-то такое говорил, мол, самый правый - тот кто пишет код? Или что-то такое.

..bw

Всё нижеследующее - IMHO.
1. Заголовок нужен. Не стоит закладываться на имя файла - содержимое файла должно однозначно определять происходящее.

Без дополнительного утиля, без hex-редакторов, можно будет простым копированием и переименовыванием добавлять в систему шрифты.

Это чушь - в любом случае шрифт нужно создавать, и без дополнительного утиля и hex-редакторов не обойтись. Кстати, как раз будет соблазн скопировать arial_8x8.fnt в arial_8x12.fnt и долго ругаться на либу, которая этого почему-то не понимает.

А если пользователь закосячил, то вместо текста у него в программах будет месево. А вот если автор либы закосячил (например, полностью полагаясь на заголовок), то приложения будут вылетать с непонятной ошибкой.

И в первом случае пользователь будет обиженно плеваться на "глючные программы, выдающие какую-то фигню", а во втором выдачи какой-то фигни не будет. Если программа не может что-то обработать, она должна об этом предупредить (сообщить об ошибке), а не выдавать ерунду.

> Еще пользователь может подсунуть не корректный файл, поменяв ему расширение и т.д. и т.п.
Он так же и с заголовком может поступить.

По статистике число пользователей, умеющих переименовывать файл, значительно больше числа пользователей, владеющих hex-редактором. А процент осознающих свои действия среди переименовывающих файлы соответственно значительно меньше процента осознающих свои действия с hex-редактором.
2. Идея перебора всех файлов и дальнейшем выборе среди них наиболее подходящего всё-таки не смотрится. Во-первых, загружается куча ненужной информации. Во-вторых, могут быть разные шрифты для одного и того же размера (Arial и Courier, скажем) - логичнее загружать шрифт всё-таки по имени. В-третьих, все шрифты одного начертания (Arial всех размеров) лучше хранить в одном большом файле, содержащем все заложенные размеры.

Заголовок нужен. Всё равно библиотеке придётся создавать структуру данных с параметрами шрифта. Так пусть она будет в заголовке. Но я согласен с bw в отношении новых форматов. Хотелось бы работать с уже существующими форматами.

В папке fonts лежат борландовские шрифты. На фига ?

В папке fonts лежат борландовские шрифты. На фига ?

Потому что есть стандартный подключаемый файл для работы с ними и есть демка bgitest, демонстрирующая их вывод.

> в любом случае шрифт нужно создавать
Если ты читал мои сообщения внимательно, хотя это и так известно. Уже существует масса битовых шрифтов в raw формате. У меня где-то коллекция валяется (с 10 файлов). Если поискать в интернете, можно еще тучу их найти.

> По статистике число пользователей, умеющих переименовывать файл, значительно больше числа пользователей, владеющих hex-редактором.
Ну если ты расчитываешь на такого пользователя, то расчитывай и на то что он не только имя шрифта может изменить, но так же может переименовать библиотеку, приложение, ресурсы, а то и перенести их в ту или иную директорию. Что-то я не замечал особых мер, которые бы принимались по такому поводу в KOS.

> все шрифты одного начертания (Arial всех размеров) лучше хранить в одном большом файле, содержащем все заложенные размеры
Вот как раз для этого и стоило бы подумать над отдельным форматом. А существующие raw-шрифты оставить в покое, с миром :-).

..bw

Но кроме этой демки есть программы их использующие ?

Rtf read юзает их, но эта программа отстой и её вообще надо убрать из дистра вместе со всеми этими неиспользуемыми шрифтами.
Или модернизировать её.

to all
Итак, стоит прекратить спор, я высказал идею, которую мне реализовывать. С другим форматом нужно иметь его описание, структуру, если у кого-то имеется такое описание прошу ссылку на доку.
Иметь 1 огромный файл, который будет содержать все форматы можно. Однако, размер его будет ~10 или более Мб (для каждого разрешения своя картинка + заголовок).
Свой формат шрифтов рассматривается как наиболее подходящий для работы с 65 функцией. В любом случае для вывода из любого другого, допустим векторного формата, нужно будет преобразовать текст в raw картинку.
Итак если будет дока на адекватный формат raw шрифта, я сделаю его поддержку.