Проектирование браузера
От: belf Meta
Дата: 15.12.04 01:01
Оценка: 39 (2)
Здравствуйте, c-smile, Вы писали:

> [...]


Думаю что эта заметка будет вам интересна
http://slashdot.org/articles/04/12/14/1443203.shtml?tid=113

Best regards,
Aleksey Chernoraenko.




18.12.04 21:22: Ветка выделена из темы Новый browser и JavaScript
Автор: c-smile
Дата: 09.12.04
— AndrewVK
18.12.04 21:23: Перенесено модератором из 'Философия программирования' — AndrewVK
Re[2]: Проектирование браузера
От: c-smile Канада http://terrainformatica.com
Дата: 15.12.04 06:16
Оценка:
Здравствуйте, belf, Вы писали:

>> [...]


B>Думаю что эта заметка будет вам интересна

B>http://slashdot.org/articles/04/12/14/1443203.shtml?tid=113

О! Классно, спасибо Алексей!

На самом деле мы в общем и целом не собираемся строить browser общего назначения.
Если кто другой возмется всю положенную обвязку делать — side bars, history, etc. мы только приветсвовать будем.

Тот броузер который мы делаем a) демонстрация engine б) сугубо минималистский инструментальный броузер.
Компактный и легкий. И полезный. Т.е. например там будет функция "CSS inspector" —
указав "пальцем" на элемент можно будет получить репорт типа:
element "div" class="..."
    ....
    margin-left:12pt  - set by selector: "LI > DIV" file: main.css, line 44;
    ....


Кроме того например там будет встроенный редактор (WYSIWYG) линейного HTML — типа
Wiki разметки. Собственно Wiki разметка (или т.н. BB codes) как формат пересылки редактируемых человеком
данных по всей видимости самое оно. Зверь из Харькова взялся помочь с Вики — спасибо ему.

Мой опыт говорит что HTML+CSS не подходит для WYSIWYG редактирования ну никак.
Мусор на выходе неудобоваримый.

Человек при редактирвании не оперирует понятиями cascading или вложенность
тэгов. Т.е. нужно нечто линейное, например Wiki формат, как наиболее полная разновидность на сегодняшний день.
В принципе мой эксперимент с BlockNote (http://blocknote.net) считаю удачным. Он как раз в этой струе.
Пользователи — те люди которые и знать ничего не хотят про HTML но писать хотят и очень.
Хотя я изнаю каждый тэг в лицо что называется, но меня унижает писать тексты в кавычках разметки. Я например замечаю что делаю кучу "очепяток" когда пишу в RSDN редакторе... То ли фонт не тот то ли формат, в BlockNote на порядок лучше... Вот кстати наша http://terrainformatica.com пишется в BlockNote.

Вот я и хочу предложить наш browser тем людям — фирмам которым нужно то что называется CMS (content management system)
Не лепить WYSIWYG на том что не приспособлено ну никак, а дать спец. броузер для этого. Т.е. страницы для редактирования контента могут быть "заточены" под единственный броузер — наш. И не надо мучаться с поддержкой того -сего. Это ж сколько времени уходит... Згрузить еще один броузер размеров в 500k в зипе сейчас ну просто ничего.

В принципе броузеров должно быть много. Т.е. не обязательно закладываться на проценты в логах как на основную мотивацию. На мобильных девайсах например своя специфика и тащить туда Mozilla со всем хозяйством просто смысла нет. Там другие экраны — суть другой принцип browsing.

Вот такая философия.
Re[3]: Проектирование браузера
От: McSeem2 США http://www.antigrain.com
Дата: 15.12.04 16:01
Оценка: 93 (6)
Здравствуйте, c-smile, Вы писали:

CS>Кроме того например там будет встроенный редактор (WYSIWYG) линейного HTML — типа

CS>Wiki разметки. Собственно Wiki разметка (или т.н. BB codes) как формат пересылки редактируемых человеком
CS>данных по всей видимости самое оно. Зверь из Харькова взялся помочь с Вики — спасибо ему.

Андрей, ты будешь мощно смеяться (а уж у Влада вообще истерика случиться — пусть порадуется), но для antigrain.com я не придумал ничего лучшего, чем сделать даже не велосипед, а колесо. По мотивам обсуждения здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=520757
Автор: McSeem2
Дата: 27.01.04


Собственно, процитирую себя ненаглядного:

Хочу следующего:

— На входе — Plain Text с простым синтаксисом типа Wiki, ни к коем случае не XML (что XML, что HTML, что прочие там SGML — вообще не для людей языки).
— Простота использования. Не хочется тратить столько же времени на освоение, как и на новый язык программирования.
— Сравнитенльно простой конфиг-файл, определяюший синтакс результата (для HTML или XML — просто набор тэгов, определяющих обрамление элементов — параграфы, списки, таблицы, оглавление и т.д.).
— Возможность (хотя-бы потенциальная) конвертировать исходники в разные другие форматы.
— Автоматическая раскраска кода.
— Автоматическая сборка оглавления и глоссария по специальным образом помеченным словам/предложениям.
— Автоматическая расстановка кросс-ссылок по словарю глоссария в тексте и в коде.


Изначально antigrain.com делался на голом HTML, как оно меня достало! тайбл-тр-тд-тр-тд-тр-тд-тайбл
И никакие ФронтПапги здесь не помогут. Потом поглядел-поизучал и таки сделал. И переделал весь сайт на этой "шняге". Собственно, здесь, с более развернутой мотивацией:
http://antigrain.com/agdoc/index.html

То есть, пишу я примерно так (это просто некий тестовый пример, текст в ней смысла не несет) :
http://www.antigrain.com/agdoc/test.agdoc.html

Получается, например, вот:
http://www.antigrain.com/agdoc/test_project/output/test.agdoc.html

Все никак не соберусь TeX изучить и сделать конфиг для него, чтобы еще и качественный PDF генерировать прямо из того, что есть. А, кстати, может DocBook лучше? Из него можно хороший PDF сделать? Для более формализованного DocBook'а конфиг файл был бы значительно проще, даже проще, чем сейчас для HTML

На все про все у меня ушло не больше 2-х месяцев маньячения по вечерам. Как говорится "лучше день потерять, зато потом за 5 минут долететь"
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Проектирование браузера
От: Зверёк Харьковский  
Дата: 15.12.04 17:17
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, c-smile, Вы писали:


CS>>Кроме того например там будет встроенный редактор (WYSIWYG) линейного HTML — типа

CS>>Wiki разметки.
...
CS>>Зверь из Харькова взялся помочь с Вики — спасибо ему.
I am.


MS>Потом поглядел-поизучал и таки сделал. И переделал весь сайт на этой "шняге". Собственно, здесь, с более развернутой мотивацией:

MS>http://antigrain.com/agdoc/index.html

MS>То есть, пишу я примерно так (это просто некий тестовый пример, текст в ней смысла не несет) :

MS>http://www.antigrain.com/agdoc/test.agdoc.html

MS>Получается, например, вот:

MS>http://www.antigrain.com/agdoc/test_project/output/test.agdoc.html

Почитал внимательно.
Презанятно.
Особенно понравилось выравнивание в таблицах.

Несколько вопросов:
— pre?
— вложенные таблицы?
— внутренние вики-образные линки? (они тебе и не нужны были)
— переменные?
— definition list?
— просто строчка с отступом?
— hr?
— комменты? (текст, который видно только в исходниках?)
— html? (для задач, с которыми разметка не справляется)

Для сравнения: http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#The_wiki_markup

Знаешь, в чем основная разница? Вики-разметку сложнее парсить, но она немножко "понятнее" выглядит (в том смысле, что по "исходнику" видна организация текста). Зато ее парсер безумно тяжело формализовать (я попытался разбить это дело на "описание правил" и "применение правил", в конце концов, забил).
сам слушаю и вам рекомендую: The Mill — Werewolf
FAQ — це мiй ай-кью!
Re[5]: Проектирование браузера
От: McSeem2 США http://www.antigrain.com
Дата: 15.12.04 21:16
Оценка: 21 (2)
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Почитал внимательно.

ЗХ>Презанятно.
ЗХ>Особенно понравилось выравнивание в таблицах.

Должен признать, что синтакс не блещет методологической проработкой. Для этого потребовалось бы не два месяца по вечерам. Я просто дал волю фантазии и изначально задался именно такой целью — сделать без значительных трудозатрат, чисто для себя, и чтобы оттяг получить.

ЗХ>Несколько вопросов:

ЗХ>- pre?

Называется "\as_is{...}". Почему так получилось — не помню

ЗХ>- вложенные таблицы?


Нет. Нету даже colspan/rowspan. Проблема в том, как синтаксически просто и наглядно в плоском тексте определять вложенные структуры. Но с использованием TeX-like синтакса можно хоть черта лысого:
\table{\tr{\td{\table{...}...}...}...}

Что, в общем-то уже лучше XML/HTML. По крайней мере, не так замусоривает и можно простым редактором проверять парность скобок.

ЗХ>- внутренние вики-образные линки? (они тебе и не нужны были)


Непосредственно вики-образных нет. Собирается индекс ключевых слов, для определения которых используюся метки и якоря, типа:

\label[Demo gamma_correction.cpp; anchor=PAGE_DEMO_gamma_correction]

Или:
@@label2@@

Или в исходниках:
    //-----------------------------------------------------intersect_rectangles
    template<class Rect> 
    inline Rect intersect_rectangles(const Rect& r1, const Rect& r2)

После чего PAGE_DEMO_gamma_correction, label2 и intersect_rectangles распознаются как ключевые слова.

ЗХ>- переменные?


В конфиге можно определять переменные:

\code_background         [ #f4f4f4 ]
\code_main_color         [ #130f00 ]
\code_rem_color          [ #4c8d00 ]


И использовать: "$(code_background)". Выполняется простая контекстная подстановка, поэтому, можно написать так:

\main_font [Verdana, Arial, Tahoma]
\mono_font ["courier new", courier,mono]
\all_fonts [$(main_font), $(mono_font)]


В результате $(all_fonts) развернется в "Verdana, Arial, Tahoma, "courier new", courier,mono"

ЗХ>- definition list?


Нету.

ЗХ>- просто строчка с отступом?


Специально нету, но добавить некий элемент в конфиг несложно.

ЗХ>- hr?


----- или \hr

ЗХ>- комменты? (текст, который видно только в исходниках?)


%%% — строчный
%%* Blah-Blah *%% — блочный
Это hardcoded

ЗХ>- html? (для задач, с которыми разметка не справляется)


Нету. Технически несложно, но куда его девать, если надо будет сгенерироватиь TeX?

ЗХ>Для сравнения: http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#The_wiki_markup


О! Я смотрю, вики сильно вырос с тех пор. Собственно, он-то меня и сподвиг на это дело. Не хватало раскраски кода, определяемой по своим правилам. Сначала я хотел поискать имплемиентации вики и прикрутить раскраску кода туда, но потом решил поступить по-другому. Основная синтаксическая конструкция — это
\element[attributes]{content}

Attributes и content не являются обязательными.
Основные wiki-like элементы определяюся в конфиге примерно так:

\singletons
[ 
    ----  hr
    --    emdash
    (C)   copy 
    (R)   reg 
    (TM)  trade
    ...   hellip
    ^o    deg
    ^1    sup1
    ^2    sup2
    ^3    sup3
    ~_    nbsp
    +-    plusmn
    <->   harr
    <-    larr
    ->    rarr
]

\pair_quotes
[
    '' sq
    "" dq
    << aq
    >> aq
    $$ m
    ### code
    ** b
    ~~ i
    *~ em
    ~* em
    __ u
    ^^ sup
    vv sub
    == nobr
    @@ label
]


После чего, например, "(C)" превращается в "\copy{}", "**Bold**" — в "\b{Bold}" и т.д.

А уж для элементов определяются конкретная разметка:

%%% Bold
%%%-----------------
\b_open  [<B>]
\b_close [</B>]

%%% Paragraph (Justified by default)
%%%-----------------
\p_open         [<TABLE width="$(tabwidth)"><TR><TD style="text-align:justify"><P>]
\p_close        [</P></TD></TR></TABLE>]


ЗХ>Знаешь, в чем основная разница? Вики-разметку сложнее парсить, но она немножко "понятнее" выглядит (в том смысле, что по "исходнику" видна организация текста).


Согласен. Я не задавался целью сделать исходный синтакс максимально понятно выглядящим. Он должен выгдядеть разумно при разумных трудозатратах на написание парсера. Я старался не упираться ни в строго формализованный синтакс TeX (в результате чего исходный документ больше похож на программу, чем на текст), ни в "крокозябликовую" парадигму wiki. То есть, для простых элементов разметки — крокозяблики, для сложных (типа таблиц) — более формальный и гибкий TeX-like синтакс. К тому же, это позволяет очень легко создавать макро-конструкции типа:

\screenshot_open[<A href="$(this.attr.large)">
                 <IMG src="$(this.attr.small)" border="0" 
                 title="Click to enlarge"/>]
\screenshot_close[</A>]

После чего я пишу:
\screenshot[small=lion_s.png; large=lion.png]

И получаю:
<A href="lion.png"><IMG src="lion_s.png" border="0" title="Click to enlarge"/></A>



ЗХ>Зато ее парсер безумно тяжело формализовать (я попытался разбить это дело на "описание правил" и "применение правил", в конце концов, забил).


По-моему, никто никогда и не пытался этого делать. Wiki тоже развивается спонтанно.
У меня, кстати, несмотря на несколько большую строгость конструкций, все это тоже обрабатывается в 8 или 9 этапов. Так оказалось значительно проще и "модульнее".
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Проектирование браузера
От: Зверёк Харьковский  
Дата: 15.12.04 22:02
Оценка:
Здравствуйте, McSeem2, Вы писали:

ЗХ>>Несколько вопросов:

ЗХ>>- pre?

MS>Называется "\as_is{...}". Почему так получилось — не помню


Я не то имел в виду. Не отмену всех преобразований, а то, что на рсдн-не делает тег [code] — код, но без раскраски.
Кстати, о раскраске: он только по ключевым словам умеет, или html-like тоже (сложные условия типа: покрасить слово p, если перед ним есть <, а после него пары вида param="value")?

ЗХ>>- вложенные таблицы?

MS>Нет. Нету даже colspan/rowspan. Проблема в том, как синтаксически просто и наглядно в плоском тексте определять вложенные структуры. Но с использованием TeX-like синтакса можно хоть черта лысого:
MS>
MS>\table{\tr{\td{\table{...}...}...}...}
MS>

MS>Что, в общем-то уже лучше XML/HTML. По крайней мере, не так замусоривает и можно простым редактором проверять парность скобок.
Угу, понял.

ЗХ>>- внутренние вики-образные линки? (они тебе и не нужны были)

MS>Непосредственно вики-образных нет. Собирается индекс ключевых слов, для определения которых используюся метки и якоря, типа:
[погрыз объяснения]

угу, понятно.

ЗХ>>Знаешь, в чем основная разница? Вики-разметку сложнее парсить, но она немножко "понятнее" выглядит (в том смысле, что по "исходнику" видна организация текста).


MS>Согласен. Я не задавался целью сделать исходный синтакс максимально понятно выглядящим. Он должен выгдядеть разумно при разумных трудозатратах на написание парсера. Я старался не упираться ни в строго формализованный синтакс TeX (в результате чего исходный документ больше похож на программу, чем на текст), ни в "крокозябликовую" парадигму wiki. То есть, для простых элементов разметки — крокозяблики, для сложных (типа таблиц) — более формальный и гибкий TeX-like синтакс.

Кстати, вики тоже к похожему пришла: там для всего, что не укладывается в крякозяблы, используются XML-like теги.

MS>К тому же, это позволяет очень легко создавать макро-конструкции типа:


MS>
MS>\screenshot_open[<A href="$(this.attr.large)">
MS>                 <IMG src="$(this.attr.small)" border="0" 
MS>                 title="Click to enlarge"/>]
MS>\screenshot_close[</A>]
MS>

MS>После чего я пишу:
MS>
MS>\screenshot[small=lion_s.png; large=lion.png]
MS>

MS>И получаю:
MS>
MS><A href="lion.png"><IMG src="lion_s.png" border="0" title="Click to enlarge"/></A>
MS>


в Вики для этого Templates

определение:
должна быть страничка с названием Template:Screenshot и следующим содержимым:
<A href="{{{large}}}"><IMG src="{{{small}}}" border="0" title="Click to enlarge"/></a>

Использование:
{{screenshot|small=lion_s.png|large=lion.png}}


Дисклямер: я не доказываю, что Вики круче. Я делюсь опытом, с тем, чтобы мы оба, возможно, извлекли для себя что-то полезное.
сам слушаю и вам рекомендую: Unknown Artist — Track 12
FAQ — це мiй ай-кью!
Re[4]: Проектирование браузера
От: c-smile Канада http://terrainformatica.com
Дата: 16.12.04 00:41
Оценка: 44 (4)
Здравствуйте, McSeem2, Вы писали:

MS>Андрей, ты будешь мощно смеяться (а уж у Влада вообще истерика случиться — пусть порадуется), но для antigrain.com я не придумал ничего лучшего, чем сделать даже не велосипед, а колесо. По мотивам обсуждения здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=520757
Автор: McSeem2
Дата: 27.01.04

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

Как то на news... html-authoring кто-то мне ответил что "а чо HTML? За две недели твоя жена его изучит и будет на ём писать" (хорошо что моя жена того не читала, были бы этот автор "HTML за 21 день" бедный.)
Когда же я спросил про CSS... в конце концов общественность (веб дизайнеры) сказали что два года (sic!) надо.
И чем дальше тем партизаны только толще.

MS>Изначально antigrain.com делался на голом HTML, как оно меня достало! тайбл-тр-тд-тр-тд-тр-тд-тайбл

MS>И никакие ФронтПапги здесь не помогут. Потом поглядел-поизучал и таки сделал. И переделал весь сайт на этой "шняге". Собственно, здесь, с более развернутой мотивацией:
MS>http://antigrain.com/agdoc/index.html

... пропущенно ...

Я пошел по другому пути т.к. у меня Блокнот уже был. И мне в нем писать нравится.
Я просто написал PHP скрипт на сервере который оборачивает HTML страницу сделанную в Блокноте
в общий для всего сайта frame c CSS. Блокнот генерит чистый HTML 3.2 без наворотов. К тому же и PDF он умеет выдавать если надо.
А табличный процессор/редактор в нем, имхо, самый лучший. Даже вот Мозилловцы его на вооружение берут. Даниель Глазман пытается повторить фичу в редакторе NVU.

В результате получается так:
я пишу в Блокноте вот этот файл http://www.terrainformatica.com/htmlayout/main.htm
а посетитель видит его обернутым http://www.terrainformatica.com/htmlayout/main.whtm

К тому же в Windows есть такая хорошая фича : Web Folders. Это встроенный WebDAV (FrontPage Extensions) клиент.
Т.е. мой сайт и все htm на нем видны как файлы во внешнем фолдере у меня на машине. Открываю Блокнотом и пишу.
Плюс всяки мелочи — типа если TITLE начинается с '+' то на этой странице появляется раздел "Оставить комментарий".
Т.е. блогом у меня весь сайт является... Рекомендую.

MS>На все про все у меня ушло не больше 2-х месяцев маньячения по вечерам. Как говорится "лучше день потерять, зато потом за 5 минут долететь"


На написание PHP скриптов включая forum у меня ушла неделя т.к. писал китайским методом cut-n-paste. PHP я до того не знал. Смотрел изнутри движок когда-то, но и все. Кстати в PHP есть классы. Но они мне ни разу не потребовались. Нужны ли народу классы? Философский вопрос однако.

Но вот Блокнот тот да... писался 9 месяцев на полную катушку. Но тоже по вечерам.

Зато вот теперь отзывы получаю:
Последнее просто песня на израненную душу.
http://blocknote.net внизу User opinions: Ray Howe, Red Wing, Minnesota...

Ради этого стоит программировать. Это мое философское мнение такое.
Re[7]: Проектирование браузера
От: McSeem2 США http://www.antigrain.com
Дата: 16.12.04 04:30
Оценка:
Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Я не то имел в виду. Не отмену всех преобразований, а то, что на рсдн-не делает тег [code] — код, но без раскраски.


Есть, конечно. Так и называется "\code{}". Или "\m{}" для inline monospaced. Или $$monospaced$$.

ЗХ>Кстати, о раскраске: он только по ключевым словам умеет, или html-like тоже (сложные условия типа: покрасить слово p, если перед ним есть <, а после него пары вида param="value")?


Нет, раскрасчик примитивный — ключевые символы, комментарии и до 4-х категорий ключевых слов, разными цветами и стилями. Все это определяется конечно же тоже в конфиге. А для более интеллектуальной раскраски надо не мудрить, а просто приделать regexp — PCRE, например.

ЗХ>в Вики для этого Templates


Ясно. Я решил не вводить новых сущностей, а просто использовать базовый механизм

ЗХ>Дисклямер: я не доказываю, что Вики круче. Я делюсь опытом, с тем, чтобы мы оба, возможно, извлекли для себя что-то полезное.


А мне нравится вики. Что-то в нем лучше чем у меня, но парсить точно сложнее. И если бы я тогда нашел некий фришный конвертор с конфигурабельной разметкой (я нашел один, примитивный, но там было все хардкодом), то и не парился бы, а прикрутил бы раскрасчик кода и фсе
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[8]: Проектирование браузера
От: c-smile Канада http://terrainformatica.com
Дата: 16.12.04 07:05
Оценка:
Здравствуйте, McSeem2, Вы писали:

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


Я так понимаю что тебе уже как бы и не надо но вот
например BBcode parser.
http://corz.org/blog/inc/cbparser.php
Это не вики конечно но в принципе для базовых страниц сождержимого
пойдет. Там пример страницы есть.

Может кому еще сгодится.

Сам по себе "парсер" конечно как всегда в стиле PHP/Perl "в лоб" —
массив regexp'ов по очереди применяющихся к одному и тому же буферу.
Но работает. Типа, а кого волнует нагрузка процессора на арендованном серваке?
Это опять философский вопрос
Re[8]: Слезное обращение к Максу Ш.
От: c-smile Канада http://terrainformatica.com
Дата: 16.12.04 08:10
Оценка:
Здравствуйте, McSeem2,

В природе не существует векторного графического редактора
умеющего рисовать на малых пиксельных сетках в режиме WYSIWYG.

Дядько Макс, ну шо вам стоит, а?

Ну это ж изврат какой-то вечный с иконами и картинками для веб.

Признательность благодарного человечества будет обеспечена. Зуб даю (пошледний)

Народ, а давайте его сообща подвигнем?
Re[9]: Слезное обращение к Максу Ш.
От: McSeem2 США http://www.antigrain.com
Дата: 16.12.04 14:49
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>В природе не существует векторного графического редактора

CS>умеющего рисовать на малых пиксельных сетках в режиме WYSIWYG.

Мой приятель Pierre Arnaud (http://www.opac.ch/people/arnaud/) сделал на .Net нечто такое для своих нужд:
http://antigrain.com/screenshots/pictograms.png
Можешь с ним законтачить, он пришлет тестовую версию. Но там все по-французски
Там весь интерфейс (вообще весь, включая меню и иконы) рисуется при помощи AGG. Иконы рендерятся на лету из некого векторного XML-формата. Им вимимо так было проще, хотя по делу надо бы SVG.

CS>Дядько Макс, ну шо вам стоит, а?

CS>Ну это ж изврат какой-то вечный с иконами и картинками для веб.

Я бы не против, однако, у меня грядет несколько довольно значимых комерческих проектов, один из которых — имплементация эталонного SVG-тулкита, другой — с www.enthought.com, третий — с поляками по рисованию карт на всяких мобилах и т.д. То есть, я устроил некую бесплатную "замануху", а документацию (гад такой) не написал. Теперь надо расхлёбывать делая врапперы для конкретных прикладных проектов. Думаю, что по ходу дела что-нибудь можно будет изловчить и с редактором, но не прямо сейчас.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[9]: Проектирование браузера
От: Зверёк Харьковский  
Дата: 16.12.04 15:10
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Сам по себе "парсер" конечно как всегда в стиле PHP/Perl "в лоб" -

CS>массив regexp'ов по очереди применяющихся к одному и тому же буферу.
CS>Но работает. Типа, а кого волнует нагрузка процессора на арендованном серваке?
CS>Это опять философский вопрос

Ууууу.... это все очень философские вопросы насчет "в лоб".
Короче говоря, мой вики-конвертер (дядя Макс, не надо? могу поделиться ) тоже все почти "в лоб" решает — из-за большой "нерегулярности" вики-разметки.
Я покрутил-покрутил ее с недельку в попытках написать простого формата расширяемый конфиг, да и.... захардкодил.
Така грустна история.

ЗЫ: у меня в результате получился формат конфига такой, что, чтобы его разобрать, по уму надо было бы сделать еще один расширяемый парсер и конфиг к нему
сам слушаю и вам рекомендую: в тишине сижу
FAQ — це мiй ай-кью!
Re[9]: Проектирование браузера
От: McSeem2 США http://www.antigrain.com
Дата: 16.12.04 15:56
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Я так понимаю что тебе уже как бы и не надо но вот

CS>например BBcode parser.
CS>http://corz.org/blog/inc/cbparser.php
CS>Это не вики конечно но в принципе для базовых страниц сождержимого
CS>пойдет. Там пример страницы есть.

Ну это то, от чего мне хотелось избавиться в первую очередь — повторение имен в закрывающих тагах.
По этому поводу я уже высказывал мнение:
http://www.rsdn.ru/Forum/Message.aspx?mid=581531&amp;only=1
Автор: McSeem2
Дата: 24.03.04


То есть, для коротких конструкций оно еще допустимо, для длинных и вложенных — полный маздай.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[5]: Проектирование браузера
От: McSeem2 США http://www.antigrain.com
Дата: 16.12.04 16:35
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Я пошел по другому пути т.к. у меня Блокнот уже был. И мне в нем писать нравится.

CS>Я просто написал PHP скрипт на сервере который оборачивает HTML страницу сделанную в Блокноте
CS>в общий для всего сайта frame c CSS. Блокнот генерит чистый HTML 3.2 без наворотов. К тому же и PDF он умеет выдавать если надо.
CS>А табличный процессор/редактор в нем, имхо, самый лучший. Даже вот Мозилловцы его на вооружение берут. Даниель Глазман пытается повторить фичу в редакторе NVU.

CS>В результате получается так:

CS>я пишу в Блокноте вот этот файл http://www.terrainformatica.com/htmlayout/main.htm
CS>а посетитель видит его обернутым http://www.terrainformatica.com/htmlayout/main.whtm

Ага. А как с раскраской кода, автоматическими кросс-линками, сборкой оглавления и т.д?
На мой персональный взгляд, wisiwig (любой) во многих аспектах проигрывает обработке текста, как TeX/Wiki/etc. Например, я пишу "\AA", что потом разворачивается в "<B>Anti-Aliasing</B>". Всякие Ворды для этого используют автозамену. Но эта автозамена — одноразовая! Если мне надо поменять что-то, например, сделать <B><I>Anti-Aliasing</I></B>, я вынужден действовать уже вручную. Иными словами, многие связи между сущностями теряются. Но, безусловно, wisiwig-системах есть автоматизации, принципиально недоступные пакетным текстовым процессорам, например пометка о обсуждение исправлений, вносимых разными людьми. В Ворде, таким образом, можно даже дискуссии вести, не теряя общего вида документа

CS>Зато вот теперь отзывы получаю:

CS>Последнее просто песня на израненную душу.
CS>http://blocknote.net внизу User opinions: Ray Howe, Red Wing, Minnesota...

CS>Ради этого стоит программировать. Это мое философское мнение такое.


Прими мои искренние поздравления. Кастанеда называл это "путь с сердцем".
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[6]: Проектирование браузера
От: c-smile Канада http://terrainformatica.com
Дата: 16.12.04 18:35
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Ага. А как с раскраской кода, автоматическими кросс-линками, сборкой оглавления и т.д?

MS>... я пишу "\AA", что потом разворачивается в "<B>Anti-Aliasing</B>".....

А как:
1) с раскраской кода?
я использую script на c-smile cpp2html. На самом деле скриптов такого типа вагон и маленькая тележка.

2) автоматическими кросс-линками?
Этого нет. Собственно это есть ядро функциональности Wiki.
Но думаю что прикрутить не проблема.
Например вот простой Wiki движок http://www.pmichaud.com/wiki/PmWiki/PmWiki ложится
в концепцию 1 в 1.
Т.е. вместо парсинга Wiki разметки (для вывода HTML) я могу парсить(частично) свой HTML на предмет вхождения
конструкций вида [Keyword]] что не есть проблема вообще. Regexp простейший если я все правильно понял.

То же самое и автозаменой: "оберточник" на PHP справится с задачей
замены "\AA" на "<span class=keyword>Anti-Aliasing</span>" легко. Для таких функций
собственно не важно что у тебя за текст изначально — wiki или html.

Главное то что в WYSIWYG я вижу структуру документа целиком без продирания через метатаги разметки.
В wiki and the like плохо то что нужно постоянно preview делать транслируя в уме туда сюда HTML<->WIKI

3) сборкой оглавления и т.д?
Статическое оглавление по набору <H1>, <H2>, ... в тексте или текстах собрать не проблема.
Динамическое же не знаю — нужно ли?

CS>>Ради этого стоит программировать. Это мое философское мнение такое.

MS>Прими мои искренние поздравления. Кастанеда называл это "путь с сердцем".

Спасибо.
Re[9]: Слезное обращение к Максу Ш.
От: McSeem2 США http://www.antigrain.com
Дата: 17.12.04 04:54
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>В природе не существует векторного графического редактора

CS>умеющего рисовать на малых пиксельных сетках в режиме WYSIWYG.

Я даже больше скажу. Толковых векторных редакторов общего назначения вообще не существует. Упомяну только несколько совершенно тривиальных возможностей, которых я не видел ни в одном из доступных редакторах.

1. Рисование произвольного пути с возможностью оперативного переключения примитивов. Обычно, выбираешь либо freehand, либо brzier curves, либо просто полигон. А хочется начать рисовать с отрезка, потом не теряя целостности переключиться на кривую, потом добавить дугу, потом — freehand, потом — опять отрезок, потом — cardinal curve, и т.д.

2. Возможность выбирать и трансформировать не только целые примитывы/группы, но и отдельные точки. Вот я рисую диаграмму, к некому прямоугольнику подходят много стрелок. Мне понадобилось сдвинуть прямоугольник со всеми линиями, к нему подходящими, так, чтобы линии были как-бы резиновыми. Фиг с ним, что линии с чем-то могут пересечься, я это потом поправлю. Мне достаточно лишь минимальной автоматизации рутинных операций, чтобы не заниматься мышиным петтингом для каждой линии в отдельности.

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

4. Управление гамма-коррекцией отдельно для каждого примитива или группы примитивов. Помню давнюю статью Ромы Воронежского, где он рисовал сглаженные углы округлого прямоугольника вручную по пикселам(!) и таким образом доказывал, что "руки рулят". Визуальный результат у него был несомненно хорош. Руки-то рулят, но если подумать, то умственный мозг рулит лучше. А проблема в том, чтобы можно было управлять гамма-коррекцией сглаживания (anti-aliasing) для отдельно взятого объекта. И никакого рукоблудия, все происходит автоматически.

5. Дублирование мыши клавиатурой для пиксельного и субпиксельного позиционирования. Мышь — интструмент очень грубый. Фактически, мышь хороша только для тыкания по контролам и ссылкам. Ну и для грубой навигации при рисовании. Точная подгонка должна всегда осуществляться стрелками.

6. Покажите мне того идиота-дауна, который внедрил схему press-drag-release для рисования отрезков. Подозреваю, что это товарищ Apple, но не уверен. Возможно, что и товарищ Microsoft. Рисование отрезков должно работать по схеме click-drag-click. Если найдутся несогласные, буду рад аргументированно аргументировать аргументами.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[10]: Слезное обращение к Максу Ш.
От: c-smile Канада http://terrainformatica.com
Дата: 17.12.04 05:16
Оценка:
Здравствуйте, McSeem2, Вы писали:

CS>>В природе не существует векторного графического редактора

CS>>умеющего рисовать на малых пиксельных сетках в режиме WYSIWYG.

MS>Мой приятель Pierre Arnaud (http://www.opac.ch/people/arnaud/) сделал на .Net нечто такое для своих нужд:

MS>http://antigrain.com/screenshots/pictograms.png

Кул! Да, тесен этот мир... Я за Пьером давно слежу. В свое время
Его тулкит OPaC (aka "Bright ideas" если не ошибаюсь) меня оченно интересовал.
Жаль что он почему-то не пошел. Архитектура там была получше чем у FLTK того же.

MS>Можешь с ним законтачить, он пришлет тестовую версию. Но там все по-французски

MS>Там весь интерфейс (вообще весь, включая меню и иконы) рисуется при помощи AGG. Иконы рендерятся на лету из некого векторного XML-формата. Им вимимо так было проще, хотя по делу надо бы SVG.

Я конечно попробую. Но на самом деле я имею ввиду немного другое (см. ответ на след. пост).

CS>>Дядько Макс, ну шо вам стоит, а?

CS>>Ну это ж изврат какой-то вечный с иконами и картинками для веб.

MS>Я бы не против, однако, у меня грядет несколько довольно значимых комерческих проектов, один из которых — имплементация эталонного SVG-тулкита, другой — с www.enthought.com, третий — с поляками по рисованию карт на всяких мобилах и т.д. То есть, я устроил некую бесплатную "замануху", а документацию (гад такой) не написал. Теперь надо расхлёбывать делая врапперы для конкретных прикладных проектов. Думаю, что по ходу дела что-нибудь можно будет изловчить и с редактором, но не прямо сейчас.


Вот на этой "заманухе" и держится весь OpenSource.

Я давно подозревал что каждый программер в душе хохол.
"Нащо тий сырэць тебе потрибен, г`а?!" — "Та щоб було!" —
— "Або воно було сало, я б ще зрозумив..."

Лично я предпочитаю компоненты — ящики с четкими педалями куда давить и где получать.
А сырцы... Эх... "Многия знания — многия печали"...
Некоторые — глаза б мои не видели...
Re[10]: тогда: Обращение к Общественности!
От: c-smile Канада http://terrainformatica.com
Дата: 17.12.04 05:50
Оценка:
CS>>В природе не существует векторного графического редактора
CS>>умеющего рисовать на малых пиксельных сетках в режиме WYSIWYG.

MS>Я даже больше скажу. Толковых векторных редакторов общего назначения вообще не существует....


{ поскипано, солидарен и согласен полностью }

Есть Xara но она на пикселах.... ну вы поняли...
Ну на кой ляд мне скажите упала позиция конца отрезка в x = 12.67 пиксела? вообще. В чем философский смысл этого числа?

Что бы хотелось: иметь хотя бы половину того что есть в Xara, но!
Видеть изображение в пикселной сетке (например Zoom в Paint.exe)
Позиционировать буквы, фигуры, отрезки на центры пикселей!

И все хранить в векторе. Чтобы можно было строить иконы/картинки разных размеров без
маразма. Да с Альфой. Да с учетом Гаммы.

Господа, кто ищет тему для шаровары, вот конкретный проект.
Он будет востребован точно.
В зависимости от исполнения — 400-800 USD ежемесячно. Это мой прогноз.
Обязуюсь помочь чем смогу. Могу предоставить свои сайты и субдомены для хостинга оного редактора.
Могу презентовать hsmile/csmile engines чтобы не заморачиваться на всяки диалоги и лайауты экранов — плюс переносимость в т.ч. на Мак. Плюс ссылки всяки на начальную раскрутку.

Осалось только договориться с Максом.
В предлжении есть три смысловых бизнес слоя. В том смысле что выгоду получат все три стороны, гарантирую.


Философский вопрос вопрос в сторону:
Ну какой xxx придумал (например в GDI) что point(0,0) это левый верхний угол пикселя?
Принтеру и всем остальным с DPI > 300 все равно где этот угол, а на экране вечный кайф — здесь right-bottom внутри там снаружи — тьфу, теоретики, етить...
Re[11]: тогда: Обращение к Общественности!
От: McSeem2 США http://www.antigrain.com
Дата: 17.12.04 07:14
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Есть Xara но она на пикселах.... ну вы поняли...


Я купил XaraX года 3 назад и пользуюсь ей. Хороший редактор, но, блин, это какой-то просто рак головы (но другие редакторы еще хуже).

CS>Ну на кой ляд мне скажите упала позиция конца отрезка в x = 12.67 пиксела? вообще. В чем философский смысл этого числа?


Эээ. Проблема не в этом. Проблема в адекватности. Вот, простейший пример, только что сделал:

Верхний прямоугольник — это то, что мы видим на экране, нижний — то, что получаем в GIF/PNG/etc. Любой веб-дизайнер от такого беспредела застрелится. Как можно ошибиться на целый пиксел?!

Как-то давно один мой знакомый мастер-столяр, в голодные времена становления комерческих структур устроился на работу в какую-то шаражку по изготовлению деревянных дверей и рассказывал о творящемся там беспределе:

- Представляешь, там какой-то хмырь берет сухую, 3 года выдержанную доску, отмеряет 2 метра, отпиливает и ошибается на миллиметр! Как можно ошибиться на целый миллиметр?!!!

Кстати, в так называемой "графике нового поколения", GDI+, даже кривую Безье нельзя толком нарисовать. То есть, в 99% случаев она рисуется нормально, но в остальных случаях — промахивается мимо конечной точки на целый пиксел или даже два. Как можно промахнуться на целый пиксел?!

Ну это все так, лирика.

Что же касается x=12.67, то это как раз нормально. Ненормально то, что этим нельзя толком управлять. Не секрет, что даже простые отрезки Брезенхема должны выглядеть по разному:
(10.00,10.00) -> (12.00, 15.00)
и
(10.00,10.00) -> (12.67, 15.00)

CS>Что бы хотелось: иметь хотя бы половину того что есть в Xara, но!

CS>Видеть изображение в пикселной сетке (например Zoom в Paint.exe)
CS>Позиционировать буквы, фигуры, отрезки на центры пикселей!
CS>Философский вопрос вопрос в сторону:
CS>Ну какой xxx придумал (например в GDI) что point(0,0) это левый верхний угол пикселя?
CS>Принтеру и всем остальным с DPI > 300 все равно где этот угол, а на экране вечный кайф — здесь right-bottom внутри там снаружи — тьфу, теоретики, етить...

Отрезок — это не такая простая фигура, как кажется. С точки зрения грамотного анти-алиасинга и субпиксельной точности, отрезок — более сложный примитив, чем полигон. Так вот, полигоны должны отсчитываться от левого-нижнего угла пиксела (я считаю, что ось Y идет как положено, то есть вверх), а линии — от центра. Но вообще-то, это неразрешимая задача, я об этом писал:
http://www.antigrain.com/tips/line_alignment/line_alignment.agdoc.html

Всякие Microsift'ы подобных проблем просто не замечают, они о них просто не знают — чего там какие-то пикселы считать?

CS>Осалось только договориться с Максом.

CS>В предлжении есть три смысловых бизнес слоя. В том смысле что выгоду получат все три стороны, гарантирую.

Я могу войти в долю, сделав собственно рендерер, то есть набор классов типа Java2D или Quartz с необходимой функциональностью для рисования как основного канваса, так и контролов. Разумеется, со всеми прибамбасами, гаммами и прочими омегами.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[12]: тогда: Обращение к Общественности!
От: c-smile Канада http://terrainformatica.com
Дата: 17.12.04 08:04
Оценка:
Здравствуйте, McSeem2, Вы писали:

MS>Эээ. Проблема не в этом. Проблема в адекватности. Вот, простейший пример, только что сделал:

MS>
MS>Верхний прямоугольник — это то, что мы видим на экране, нижний — то, что получаем в GIF/PNG/etc. Любой веб-дизайнер от такого беспредела застрелится. Как можно ошибиться на целый пиксел?!

Вот оно! "Халяушики" (С) Лукашенко.

MS>Что же касается x=12.67, то это как раз нормально. Ненормально то, что этим нельзя толком управлять. Не секрет, что даже простые отрезки Брезенхема должны выглядеть по разному:

MS>(10.00,10.00) -> (12.00, 15.00)
MS>и
MS>(10.00,10.00) -> (12.67, 15.00)

Согласен! За! Теорию знаю! Твою статью прочитал в свое время, кул! Но!
Мне не надо 12.67! Вообще! У меня в то место палец попасть вообще не должен.

Как художник художнику:

У меня 16 на 16 пикселей. Итого 256 родимых.
Я хочу что-бы линия начиналась пикселом № 21 и заканчивалась № 220.

Начало и конец — это принципиально. Как она раскрасится посредине (линия наклонная) это уже не важно (лишь бы "антиалиаснуто").

Если я захочу то я могу выставить на самом деле и 12.67. Хочу я этого числа правда не часто.
Т.е. нужен snap-to-grid с интеллигентной оптимизацией от "антиалиасера" в случае привязанного (snap'нутого) отрезка.
Вот. Это конечно не строгое определение но близко.

MS>Я могу войти в долю, сделав собственно рендерер, то есть набор классов типа Java2D или Quartz с необходимой функциональностью для рисования как основного канваса, так и контролов. Разумеется, со всеми прибамбасами, гаммами и прочими омегами.


Вот а еще если при этом к DOM можно будет достукиваться да c-smile(JavaScript) управлять можно вообще
строить генераторы изображений.

Да любая Вижуал Студия с руками ногами оторвет.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.