Я уже писал на эту тему - бинарный формат - это внутреннее представление, а внешний формат не нужно делать бинарным категорически.
PalmDOC, zTxt по сути разновидность архива, если бы его автор взял и сделал стандартный zip архив то мы бы про него бы и не узнали. Закладки и другие фенечки можно хранить в файлах спутниках или комментарию. Основная ценность именно ZIP - в его стандартности. Он есть на всех платформах, под все распостраненные OS.
Автор написал в первом посте - парсинг из внешнего текстового в некий внутренний бинарный - это проблема уровнем ниже чем ОТОБРАЖЕНИЕ всей этой мишуры.
Я считаю что желающие получить вывод оформления должны сделать примерно так:
Написать список видов оформления, например:
1. Текст обычный, жирный, курсив, подчеркивание
2. Разные размеры шрифта
3. Разное выравнивание для абзацев
4. Цвет символа или строки
5. Отображение картинки, как отдельного абзаца и с обтеканием
Далее нужно написать алгоритмы вывода, реализовать их на PalmOS - что и является самой сложной задачей.
Напишите навскидку быстрый алгоритм листания страниц "вверх" при таком оформлении, и подумайте что будет нужно для этого.
Только так может "родиться" нужный бинарный формат.
А уже потом можно будет думать над ним - можно ли при открытии тектового формата быстро текст преобразовать в этот бинарный формат или нужно это делать на "большом брате" как случилось с PalmDOC.
Я уже писал на эту тему - бинарный формат - это внутреннее представление, а внешний формат не нужно делать бинарным категорически.
Согласен, в том случае, если я смогу сделать бинарный файл самостоятельно и оставить его таким бинарным после того, как PaFi его создаст.
Quote:
Написать список видов оформления, например:
1. Текст обычный, жирный, курсив, подчеркивание
2. Разные размеры шрифта
3. Разное выравнивание для абзацев
4. Цвет символа или строки
Так этот список нужен, или нет? Или на тему забито в принципе?
Quote:
5. Отображение картинки, как отдельного абзаца и с обтеканием
Ох, не думаю что до этого дойдет...
Но если дойдет, то картинка, это не абзац, это буква такая.
Со всеми вытекающими последствиями. И работают с ней как с буквой.
1. Текст обычный, жирный, курсив, подчеркивание
2. Разные размеры шрифта
3. Разное выравнивание для абзацев
4. Цвет символа или строки
А нужен ли пункт 2 в чтении книг?
Вдруг кому пригодиться:) (я так понимаю, автор проекта после этого топика либо пошлет эту тему навсегда, либо все же решиться на ее реализацию) - в своем проекте я заложился на следующее:
1. Текст обычный, жирный, курсив, подстрочный индекс, надстрочный. Индексы на треть меньше по высоте, чем основная строка. Высота строки всегда одинакова (т.е. высота болда и обычного текста соответствует друг другу). Линки подчеркиваются. Если в настроках обычный текст отобрадается жирным, то то, что должно быть жирным выводиться с подчеркиванием. Если используются индексы, то стили италика и болда не учитываются.
2. Цвета задаются для текста, для заголовков и для линков.
3. Абзацы бывают
- обычный с отступом слева, переносы и выравнивания как в настройках указано.
- без отступа слева (стихи), переносы и выравнивание как в настройках.
- выравнивание по правому краю, без переносов и выравнивания (эпиграфы, подпись автора).
- выравнивание по центу, без переносов (заголовки).
- выравнивание по центру с одинаковыми отступами слева и справа, переносы как в настройках (цитаты).
4. Картинки и таблицы отображаются только на отдельном экране, т.е. никакого перемешивания с текстом. При автопрокрутке отображаются наподобие линка (надпись TABLE с шрифтовым и цветовым выделением как у ссылки).
По поводу формата - я заложился на то, что все управляющие символы идут одним потоком с текстом, используется диапазон 0x01..0x31.
Quote:
Напишите навскидку быстрый алгоритм листания страниц "вверх" при таком оформлении, и подумайте что будет нужно для этого.
да без проблем и не на вскидку. только на паскаль переделывать и адаптировать под ПФ не буду:).
P.S. А вообще тема не о том... автору никто выздоровления не пожелал, а он занемог от тяжести ваших желаний:)... И пошлет сейчас эту всю тему нафиг под воздействием грипповой атаки:)
Вы все уходите в сторону проектирования какого-то формата. А что толку в формате - если нужен ВЫВОД, которого нет и не предвидиться.
Я бы предложил желающим написать свои процедуры вывода, и предложил им то, с чего можно начать - а именно с определения того, что им нужно. Формат можно выбрать произвольный, НЕ ФОРМАТ ТЕКСТА ОПРЕДЕЛЯЕТ ВЫВОД.
Вы все уходите в сторону проектирования какого-то формата
это не формат - это внутреннее представление данных. пока оно не спроектировано - бессмысленно браться за вывод.
По поводу вывода. Насколько я понимаю, на текущий момент в ПФ есть две функции (в смысле их не может не быть:) ) - подсчет длины строки для конкретного шрифта и вывод на экран строки в конкретном шрифте.
Вывод строки с несколькими стилями сводиться к задаче разбить строку на несколько однородных кусков, и подсчитать и вывести их независимо друг от друга. Все. Других путей решения данной задачи нет. Если есть какие-либо библиотеки, то внутри они делают именно это. Что в винде, что в палмос, что еще где-то.
А вообще - вы сначала убедите автора в том, что это ему надо, а потом в том, что это вообще имеет смысл делать под палм...
По поводу вывода. Насколько я понимаю, на текущий момент в ПФ есть две функции (в смысле их не может не быть:) ) - подсчет длины строки для конкретного шрифта и вывод на экран строки в конкретном шрифте.
Вывод строки с несколькими стилями сводиться к задаче разбить строку на несколько однородных кусков, и подсчитать и вывести их независимо друг от друга. Все. Других путей решения данной задачи нет. Если есть какие-либо библиотеки, то внутри они делают именно это. Что в винде, что в палмос, что еще где-то.
Для нормального вывода больших тесктов с форматирование в палмоси нужны реализации следующих алгоритмов:
1) Подсчет высоты всего текста и/или определения текущей позиции - тут сойдет хотя бы приблизительный
2) Нахождение начала последней строки абзаца
3) Алгоритмы чтения элементов текста "назад" (т.е., в обратном направлении)
4) Разбиения абзаца на строки (причем строки могут добавляться в обоих направлениях)
5) Вычисление высоты и центра (или положения baseline) строки
Пункты 1, 2 и 3 нужны для того, чтобы не хранить в памяти весь текст.
На самом деле, реализация этих алгоритмов - вещь не очень тривиальная (учитывая малый объем памяти палмов).
Других приемлемых вариантов нету.
Опять же, реализация этих алгоритмов не слишком завязана на внешний формат данных (за исключением некоторых моментов).
При реализации алгоритмов станет понятно удобное внутреннее представление.
Может нужно хранить текст потоком - разбивая на управляющие символы? А может в виде DOM-дерева (наподобии HTML). А может в виде списка слов и списка атрибутов и таблицы связи - слово-набор атрибутов
И таких вариантов - сотни, выбор оптимального возможен только после реализации библиотеки вывода. Формат без РЕАЛИЗАЦИИ алгоритмов - ничего не дает ВООБЩЕ.
Убеждать автора не намерен. Но намерен убедить тех кто очень ХОЧЕТ форматирование текста, что им самим нужно приложить усилия в этом направлении. Ничего не мешает использовать исходники PF для создания своей читалки со своим форматом, разбивая строки как хочется и т.п.
При реализации алгоритмов станет понятно удобное внутреннее представление.
ну... тоже конечно подход:)
В принципе, если нет опыта в проектировании хоть каких-либо более менее сложных систем, так и поступают. Это после появления опыта и наработок начинают сначала думать, а потом реализовывать...
mo3r
Quote:
1) Подсчет высоты всего текста и/или определения текущей позиции - тут сойдет хотя бы приблизительный
2) Нахождение начала последней строки абзаца
3) Алгоритмы чтения элементов текста "назад" (т.е., в обратном направлении)
4) Разбиения абзаца на строки (причем строки могут добавляться в обоих направлениях)
5) Вычисление высоты и центра (или положения baseline) строки
Пункты 1, 2 и 3 нужны для того, чтобы не хранить в памяти весь текст.
На самом деле, реализация этих алгоритмов - вещь не очень тривиальная (учитывая малый объем памяти палмов).
Других приемлемых вариантов нету.
1 - не совсем понял что считать... Если ты меня цитировал, то прочел, что все строки ОДНОЙ высоты...
2,3 - зачем???
4 - есть разница в строке и строке со стилями???
5 - тоже не понимаю о чем речь...
Естественно весь текст в памяти нет смысла хранить... если уж это получается делать на мпх200, в котором практически нет памяти, то в палме это тем более не будет проблемой.
И его должно определять не в процессе болтовни на форуме а в процессе РАЗРАБОТКИ соотв. библиотеки вывода.
кого - его? Формат представления данных? Скажи пожалуйста, а что ты будешь выводить, не зная как оно храниться и откуда его брать?:) Или по частям, типа написали кусочек, теперь будем думать как сюда втулить следующий, а потом думать как обходить какой-нибудь идиотизм, который был допущен при реализации первого кусочка вывода?:)
Данный "стиль":) программирования можно допускать только в случае, если есть твердая решимость в конце цикла разработки с нуля переписать все начисто и как положено... в данном случае скорее всего этого не будет:)
По поводу трудностей в реализации - они могут быть когда плохо представляется задача и нет четкого понятия на что закладываться (все тот же формат внутреннего представления данных). Больше в этой конкретной задаче сложностей нет. В конце концов, если склероз мне не изменяет, тот же плюкер доступен в исходниках. Если все же я ошибаюсь, то библиотек под винду которые реализуют вывод на экран, тоже не мало - подсмотреть что и как кто-то уже реализовывал всегда можно... Те же мобипокеты и исилы работают с форматированием под палм ос - следовательно непреодолимых сложностей нет.
Quote:
Все остальные разговоры без этого - пустая болтовня.
А вот это золотые слова... никаких возражений не может быть.
Так что хватит болтать и займитесь (те кого интересует поддержка стилей текста) делом... В конце концов там писать меньше, чем языком трепать - у меня на такую библиотеку ушло две недели... На палме из-за маразма со шрифтами уйдет больше...
Да и найдите наконец кому это надо из людей, кто может что-то написать...
Если ты меня цитировал, то прочел, что все строки ОДНОЙ высоты...
Тогда всесильно проще.
Quote:
А вот это золотые слова... никаких возражений не может быть.
Так что хватит болтать и займитесь (те кого интересует поддержка стилей текста) делом... В конце концов там писать меньше, чем языком трепать - у меня на такую библиотеку ушло две недели... На палме из-за маразма со шрифтами уйдет больше...
Полностью согласен. Маразм со шрифтами решается за пару дней (после того, как придет понимание, как с ним бороться).
Quote:
кому это надо из людей, кто может что-то написать...
О... Браво!
Если хочешь - переходи в почту a1812lwis @@@ mail.ru - интересен подход к решению некоторых ньюансов, да и просто может помогу чем, а то по предыдущему твоему посту кажется мне, что ты некоторую лишнюю работу делаешь...
Я вот думаю, может имеет смысл забить на такие вещи как
шрифт разной высоты и картинки. Т.е. свести к тому что все строки имеют одинаковую высоту и потому размер текста по высоте будет всегда одним и тем же в независимости от состава текста. А сделать поддежку выделений шрифтом - типа начало главы и оглавление. Я думаю этого бы хватило (по крайней мере на первом этапе). И можно было бы решить - а стоит ли вообще двигаться дальше.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Rules 
FAQ 
Search 
RSS-feed 
Register 
Log in
