САПР на Lazarus

[kazalex]

Приложил свою нерабочую демку. Стоит в ней заменить 'OpenGost Type B TT' на 'times' - всё работает

У тебя там не хватает:

Код: Выделить всё

     lfcp.lfCharSet:=DEFAULT_CHARSET;


[zub]

не помогает, я уже всяко пробовал.
GetFontData - не показатель, видимо он просто возвращает данные от создания шрифта - какой шрифт создан по факту неизвестно. т.е. можно создать шрифт с любым именем, но по факту рисоваться будет шрифтом поумолчанию.
c MONACO.TTF тоже не работает

[kazalex]

не помогает, я уже всяко пробовал.

[zub]

Точно lfcp.lfCharSet:=DEFAULT_CHARSET; когда пробовал так были "мешающие" правки в других местах.
Заработало! с меня пузырь))

Добавлено спустя 7 часов 22 минуты 32 секунды:
Еще чтото не особо клеится с расчетом высоты.
Создаю все шрифты одинаковой фиксированной высоты. потом при выводе матрицей трансформации догоняю их до нужной высоты. никакие метрики шрифта в этом расчете не участвуют. только 2 высоты - созданная и необходимая и угол наклона. Результат похож, но чуток не то... На гифке парой постов выше видно разницу, идеальный вид почти без разницы можно получить введя для каждого шрифта свои масштабные коэффициенты, домножая требуемую высоту на которые будет получен почти идеальный результат.
Например для
Opengost 1.08
Arial 0.995
Times 1.063
Недогоняю откуда они вылазят такие маленькие, в метриках шрифтов ничего похожего нет, влияние DPI тоже было бы гораздо больше и одинаково для всех шрифтов

[kazalex]

На гифке парой постов выше видно разницу

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

[zub]

kazalex
Там был только ариал, ито при приближении разница была довольно заметна. Результат разницы за счет клиртайпа прилагаю.

Дальнейшие разборки показали что про маленькие коэффициенты я наврал, в расчете присутствовал еще коэффициент *96/72*1.18 как остаток какогото эксперимента. 96/72 - хз где я поглядел, 1.18 - к меня монитор 2К и включено масштабирование 118%. Экспериментировал и забыл убрать.
Чистые коэффициенты такие:
Opengost 1.6992
Arial 1.5654
Times 1.6724
Уже больше похоже на чтото что можно выудить из метрик шрифтов. Я выложил тестовую версию http://sourceforge.net/projects/zcad/fi ... z/download В ней только ГДИ рендер, и коэффициент масштабирования можно ввести в инспекторе - РендерRD_CurrentWAParamRD_SizeK - вкладка становится доступна после открытия чертежа. Тестовый чертеж можно загрузить кнопкой QL справа вверху. На тестовом чертеже "табличка" - первая строка opengost, вторая - arial, третья times. В столбцах разные наклоны текстов. Если не затруднит, попробуйте ввести коэффициенты - совпадут ли они на вашей системе и моей

Пока писал заметил "баг" - без открытого чертежа в инспекторе стоит точность отображения до второго знака, после открытия он цепляет из чертежа настройку точности до четвертого знака, но сразу не обновляется, только после какогото действия - выделитьразвыделить примитив или просто нажать еск.

Добавлено спустя 14 минут 38 секунд:
Забыл добавить, проблема именно в виндовом рендере символов - тюнить до совпадения надо его. Мой "треугольный" я сравнивал с эталонным автокадовским отображением текста, совпадение почти полное - в пределах погрешности на апроксимацию кривых

Добавлено спустя 9 часов 48 минут 31 секунду:
Разобрался, коэффициент - это (Ascent+Descent)/CapHeight У меня высота текста это высота заглавной буквы, в ttf видимо считается что это Ascent+Descent

[zub]

Назрел еще вопросик, на этот раз по логу, хоть он в зкаде и странный, но иногда выручает))
Чуток предистории:
Сначала у меня был простой лог, например:

Код: Выделить всё

programlog.LogOutFormatStr('AddEntitiesFromDXF found primitive %s',[s]);

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

Код: Выделить всё

//начало какойто процедуры
programlog.LogOutStr('Start AddEntitiesFromDXF',lp_IncPos);
...
programlog.LogOutFormatStr('AddEntitiesFromDXF found primitive %s',[s],lp_OldPos);
...
//конец этой процедуры
programlog.LogOutStr('End AddEntitiesFromDXF',lp_DecPos);

соответственно
lp_IncPos - увеличить отступ
lp_OldPos - не изменять отступ
lp_DecPos - уменьшить отступ
В лог сыплется по прежнему много, но уже покрасивее))
Тогда мне захотелось поуправлять уровнем логирования, чтобы из командной строки управлять объемом лога. Гдето в интернете подглядел как грамотеи разделяют уровень в логах и у меня получилось примерно так:

Код: Выделить всё

TLogMode=(
          LM_Trace,  // — вывод всего подряд. На тот случай, если Debug не позволяет локализовать ошибку.
          LM_Debug,  // — журналирование моментов вызова «крупных» операций.
          LM_Info,   // — разовые операции, которые повторяются крайне редко, но не регулярно. (загрузка конфига, плагина, запуск бэкапа)
          LM_Warning,// — неожиданные параметры вызова, странный формат запроса, использование дефолтных значений в замен не корректных. Вообще все, что может свидетельствовать о не штатном использовании.
          LM_Error,  // — повод для внимания. Тут интересно окружение конкретного места ошибки.
          LM_Fatal,   // — тут и так понятно. Выводим все до чего дотянуться можем, так как дальше приложение работать не будет.
          LM_Necessarily   // — Вывод в любом случае
         );

По умолчанию объем лога выставлен на уровне LM_Error, сообщения приходящие с уровнем выше в лог записаны небудут, регулировать это можно соответствующими параметрами командной строки. Соответственно вывод в лог теперь выглядит так:

Код: Выделить всё

//начало какойто процедуры
programlog.LogOutStr('Start AddEntitiesFromDXF',lp_IncPos,LM_Debug);
...
programlog.LogOutFormatStr('AddEntitiesFromDXF found primitive %s',[s],lp_OldPos,LM_Trace);
...
//конец этой процедуры
programlog.LogOutStr('End AddEntitiesFromDXF',lp_DecPos,LM_Debug);

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

Сейчас в связи с борьбой с внутренними зависимостями в программе появились места в которых хорошо бы убрать использование зкадного лога и использовать LCLный DebugLn (благо всё что туда шлется можно перехватить).
И собственно вопрос как можно юзая DebugLn не потерять возможность отступов и важности?

Первое что пришло в голову - когда надо добавлять к сообщениям соответствующие префиксы:

Код: Выделить всё

//начало какойто процедуры
DebugLn('{MD+}Start AddEntitiesFromDXF');//'MD'=LM_Debug, '+' - увеличение отступа
...
DebugLn(format(AddEntitiesFromDXF found primitive %s',[s]));//сообщения без префикса считаем LM_Trace без изменения отступа
...
//конец этой процедуры
DebugLn('{MD-}End AddEntitiesFromDXF');//'MD'=LM_Debug, '-' - уменьшение отступа

В обработчике onDebugLn на основе их восстанавливать отступ и важность и скармливать подрезаные сообщения зкадному логу. Есть какиенибудь системы логирования работающие по этому принципу?

[zub]

Сделал в варианте

Первое что пришло в голову - когда надо добавлять к сообщениям соответствующие префиксы:

Префиксы T,D,I,W,E,F,N - соответственно уровень сообщения
Префиксы +,- управление отступами
Заодно добавил префикс М - показать пользователю сообщение в месажебоксе, H - показать пользователю сообщение в окне сообщений.

Получилось вроде красиво, но в моем старом варианте

Код: Выделить всё

programlog.LogOutFormatStr('хитрый шаблон',[куча,параметров],lp_OldPos,LM_Trace);

если текущий уровень логирования ниже LM_Trace - сообщение в лог записано небудет, соответственно форматирование шаблона по параметрам не происходит.
В случае

Код: Выделить всё

DebugLn('{T}хитрый шаблон',[куча,параметров])

Форматирование шаблона выполняется сразу и только потом доходит до анализа нужно ли это сообщение в логе или нет((
Соответственно если таким способом логировать места где нужна производительность - будет существенное замедление и по сути толку от введения уровней логирования нет((

Добавлено спустя 11 минут 59 секунд:
Что можно придумать чтоб это обойти кроме:
1 - Делать своего наследника LazLogger умеющего уровни логгирования - неохота
2 - Заключать проблемные места в директивы условной компиляции - будет 2 версии программы: отладочная и рабочая, в случае проблем у пользователя придется слать ему отладочную
3 - Ввести переменную чтото типа VerboseLog и от ее состояния решать выполнять проблемный DebugLn или нет - просто но некрасиво + лишние зависимости с которыми борюсь((

[zub]

Топик этот длится с 2010 года, примерно тогда я свалил с делфи забив на совместимость с ним. о чем собственно не жалею. Единственное что хочется вернуть - возможность профайлить в aqtime.
Переодически пытался скомпилировать небольшой тестик в делфи, мешало использование TOpenGLControl - худо бедно научил зкад рисовать средствами GDI. Теперь помехой осталось только активное использование fpc-stl.
Попытки адаптировать fpc-stl для делфи успехом не кончились - нужна капитальная переработка библиотеки а не просто смена синтаксиса. Запилил "прокладку", в fpc она использует fpc-stl, в делфи generics.collections.
И ура! тестик в делфи скомпилился и даже иногда работает не падая)) а когда падает, всерано успевает отрисовать "чертежик".

Впечатления:
Потыкался в редакторе кода delphixe - по сравнению с лазарем он вызывает только маты - навигация по коду отвратительная (понимаю что xe старее поповой собаки, но не думаю что ситуация изменилась). Отладчик часто только констатирует факт вылета, не показывая где он произошел - очень стремно. Кароче всё также как было во времена делфи6-7
А вот с производительностью не всё радостно... тестик добавляет в чертеж 1е6 случайных линий, строит по ним бинарное дерево разбиения пространсива и отрисовывает
фпц:

Add lines: 11.0266 second
Rebuild spatial tree: 1.2014 second

делфи:

Add lines: 0.86 second
Rebuild spatial tree: 1.15 second

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

Погорячился))
корректный результат для фпц:

Add lines: 1.6597 second
Rebuild spatial tree: 1.2014 second

Проигрыш всего в 2 раза. живем))

[Mirage]

Форматирование в логгере свое, или SysUtils.Format()?

Кстати, софт, гляжу, серьезный.
Тут разместить есть планы?

[zub]

>>Форматирование в логгере свое, или SysUtils.Format()?
SysUtils.Format, для делфи в качестве debugln - пустые заглушки.

>>Тут разместить есть планы?
нет, не настолько серьезный))

[tema]

>>Тут разместить есть планы?
нет, не настолько серьезный))

А зря. Разместить имеет смысл. Надо развиваться!

[zub]

Какой смысл серьезно пиарить вечную недоделку - это всетаки хобби. Возможно, когда появится версия 1.0 - оочень не скоро))
С одной стороны конечно похвастать есть чем, с другой всё плачевно.
Сейчас гораздо полезней для развития найти желающих поучаствовать в "серъезном" проекте, за 5 лет таких не нашлось((

[Sharfik]

Напишу, что думаю. Сильно не бейте.
zub, ну ты сам афишируешь программу как Хобби с большой буквы. У тебя изначальная задаче к ней была, если я не ошибаюсь - сделать решение своих проблем. Не стояла задача сделать CAD программу для продажи или публичную. Я раза два пробовал вникнуть в суть твоих исходников, и разобраться как это вообще работает. Где у тебя какие части программы и как они между собой взаимодействуют. Но без документации, и тем стилем оформления исходников это вообще для меня стало нереальной задачей. Хотя бы схему классов и модель объектную как то показать, даже условно типа такой Картинка уже облегчит способ освоения кода.
Я "Pichugin Organizer" так писал, внутри бред бредом, смотря сегодняшним днем. Не умел тогда работать с классами вообще. В итоге у программы есть пара страшных багов, которые даже не вылечить толком уже, а от предложения сделать локализацию под продажу иностранным фирмам пришлось отказаться, не мог я тогда такое реализовать. Если повезет, будет новая версия, но от старой только внешность и фишки, а внутри совсем другая программа.
Наверно есть места, где ZСAD в урезанном/упрощенном виде для уменьшения багов был бы полезен, как платформа чтобы сделать например какой то генератор схем, аксонометрических проекций и т.п. Но это надо ставить цель получения денег с коммерческих его версий такой штуки. Так же как некоторые разрабатывают библиотеки чтения DWG и потом продают их по штуке баксов.
Есть куча программ, которые написаны для узких расчетов, не способных даже сохранять свои расчеты и модифицировать свою базу. Мне последние годы хотелось сделать именно такую базу, с открытым форматом хранения данных обобщенным и возможностью наращивания функционала в зависимости от плагинов. БД+CAE своеобразное. ZСAD для ряда программ там был бы к месту, поэтому и хотел разобраться как его туда прицепить можно, но не получилось. Энтузиазм дело такое, пока не доделаешь все сам до конца, и не сделаешь релиз и не попросишь денег за это, остальным не до него)))

[zub]

Sharfik
Вникнуть в суть ВСЕГО, просто взяв и скачав исходники еще долго не получится - документацию делать и поддерживать в актуальном состоянии пока не имеет смысла - многие моменты часто переделываются.
Прошу тут делать мне скидки - проект довольно большой. Но я всегда могу ответить на вопросы и внести требуемые доделки.
Я бы выделил несколько основных частей из которых состоит зкад:
1-движек - отображение и редактирование примитивов - там сплошная магия, я туда не выпив пива и не перекрестясь стараюсь не лазить))
2-примитивы - единственное место про которое можно дать картинку иерархии классов, но чтобы добавлять новые примитивы надо чуток знать как работает движек
3-команды - то что вызывается пунктами меню и кнопками - интерактивное создание примитивов, открытие разных окошек и т.п.
4-гуй - отдельные окошки всё как обычно редактор форм и т.п., вместе всё клеится анхордокингом

Пункты 3 и 4 сложности имхо вызывать не должны, если иметь представление как работают кад программы
Для использования потрохов зкада в сторонних приложениях в качестве примера я сделал simplecad. После наших разговоров он стал "очень самостоятельным" - просто exe без рантайм окружения, единственный момент который остался - для записи dxf пока все же требуется внешний файл с "шаблоном" - никому запись пока не была нужна, поэтому не поправил этот момент

Если вдруг решишь попробовать вникнуть третий раз - дай знать, после небольших вводных разъяснений будет проще