РАБОТА С БОЛЬШИМИ ИЗОБРАЖЕНИЯМИ В ПРОГРАММЕ DAL_2_HTML v.0.85

Вложение:dal2_085.rar[776.04 КБ]
Скачиваний: 505


В архиве dal2_085.rar, кроме исполняемого файла, файлов исходного кода, файлов проекта
и файлов конфигурации программы содержатся текстовый файл и все изображения,
нужные для создания схемы "Дачные прогулки"

Вложение:
52_3.jpg [ 818.35 КБ | Просмотров: 12697 ]


Все делается в спешке, т.к. свободного времени как обычно не хватает.
Да и на этой неделе свободного времени было мало, поэтому работу с
большими визуальными схемами мне удалось проверить только вчера.
(но, вообще говоря, как концептуальный макет, пригодный для развития
другими программистами, версия 0.84 свою задачу решает, внесенные
в версию 0.85 исправления касаются частностей, хотя и имеющих
значение при практической работе по созданию визуальных схем)

Выяснилась такая вещь.
При приближении размера jpg-файла к 1 Мб и размера bmp-файла к 100 Мб
библиотеки Delphi 4 (а может, Windows XP) отказываются работать с
графическими файлами таких размеров, кстати браузер тоже отказывается
открывать bmp-файл такого размера.
Понятно, что конкретные цифры тут зависят от объема оперативной памяти
компьютера и еще много от чего, но тенденция понятна.

Как отказываются ?
При генерации htm-файла начинают всплывать окна с сообщениями
"JPEG error #36" и "недостаточно памяти для выполнения задачи".
Это только одна из причин, почему я не захотел встраивать генерацию
htm-файла в графическую оболочку dalvjaz2.
А ведь если ты встроил, а у тебя постоянно лезут при малейшем чихе
системные сообщения об ошибках, то потенциальные пользователи вряд ли
будут в восторге от этого.
Понятно, как с этим бороться - нужно искать и подключать
специализированные графические библиотеки, а для этого у меня нет ни
свободных моральных сил, ни свободного времени, ни желания.


Как я это проверял - просто копировал весь текст начиная с первого
"* если" и заканчивая последним "* конец" в буфер обмена и вставлял
прямо перед действием "* выход"
подсистема jpeg не выдержала даже удвоения, т.е. для нее визуальные
схемы размера "Морозко" или "Дачные прогулки" уже приближаются к
максимальной границе.
Подсистема bmp выдержала четырехкратное увеличение размера и заткнулась
с сообщением "недостаточно памяти для выполнения задачи" при
пятикратном увеличении размера исходного текстового файла.

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

Для справки приведу сравнительные размеры jpg и bmp файлов:
для существующего размера схемы "Дачные прогулки" получаем, что размеры
jpg в зависимости от используемых стилей колеблются в пределах от 815Кб
до 850Кб, а размер bmp составляет чуть больше 33Мб.

(для сравнения - размер цикла-силуэта u_dalvj.23 "подсчитываем размер схемы",
не включающего рисунков, равен чуть меньше 315Кб)

При двукратном увеличении размера исходного текстового файла, когда
jpg уже не работает, размер bmp превышает 52Мб, и браузер этот файл
просматривает.

Я включил в dal2htm.cfg параметр
__генерация_bmp          "0"    ; 0/1 - установить в 1, если возникают
;                                 проблемы с генерацией jpg

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

Вот тут и вступает в дело html.

Допустим, у нас в сгенерированном файле с десяток схем размером со
схему "Дачные прогулки".
Тогда в действии "* выход" каждой из них можно сделать ссылку "_>.N"
на ту схему, которая будет продолжением.
Кстати, необязательно в действии "* выход" - ссылку на другие схемы
можно вставлять в любом действии.
Кроме того я подумал, что было бы удобно, если бы по ссылке действия
можно было бы открыть произвольный html-файл.
Теперь эта проблема решается так:

* если  [-]    _><a href="../dalvj2.htm#i.2">dalvj2.2</a>

т.е. после определителя ссылки программы dal2html помещаем стандартную
html-ссылку.



html-файл, содержащий только схемы

Теперь описание модуля в dal2htm.cfg выглядит так:
## Код:
```
;                                                        в htm-файл:
; N модуля     N    ссылочный  имя                       1: схемы
;            ката-  N модуля   файла                     2: схемы и
;            лога   м.б.>100                ПРОСМ/---       текстовые записи       
;                                                        3: схемы и все записи
...
__модуль07   "02>     52       dacha.txt      ПРОСМ           1"
```

Т.е. html-файл превратился в галерею рисунков, но не простых, а таких,
в которых можно задавать логические связи между элементами рисунка, а
также гиперссылки на другие рисунки и на произвольные html-файлы.

Теперь файлы схем не обязаны находиться в рабочем каталоге, куда будут
помещаться сгенерированные html-файлы, а могут находиться и в одном
из подкаталогов рабочего каталога, имя которого задается в dal2htm.cfg.

При тестировании программы dal2html со схемой "Морозко" (выложенной
в конце прошлого года в теме "Программы AB_VJAZ и DAL_VJAZ", у которой
размер по вертикали значительно больше размера по горизонтали) с разными
стилями отдельных блоков выяснилось, как минимум по оси У есть небольшая
погрешность в подсчете размеров схемы, которая при большом размере схемы
по У привела к тому, что половина блока "* выход" (конец схемы)
выехала за границы схемы.
В чем тут дело, я пока не разобрался, поэтому на всякий случай решил
окружить схему на листе схемы рамкой размером 100 пикселей и вообще
вынести задание расстояний схемы от границ листа схемы в dal2htm.cfg.

Кроме того, я вынес в dal2htm.cfg задание базовых размеров схемы bdx
и bdy, от размеров которых зависят размеры между элементами схемы
по вертикали и горизонтали, а также размеры выступающих треугольников
блоков условий.
Сейчас bdx и bdy равны:
bdx = ширина символа фонта 'Courier New', 9
bdy = (высота символа фонта 'Courier New', 9) + 2


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