Файлы CGM неправильно масштабируются в FrameMaker — требуется ли значение секретного флага?

У нас есть код, который напрямую записывает файлы CGM (или интерактивные WebCGM). У нас есть полный контроль над всеми примитивами CGM и мы можем генерировать файлы версии 1, 3 или 4 по мере необходимости. В общем, CGM, который мы пишем, прекрасно визуализируется в различных стандартных рендерерах (MetaWeb, SDI, ISOView и т. д.) — эти рендереры позволяют нам масштабировать, панорамировать или масштабировать без дефектов.

К сожалению, у нас есть проблема, когда конечный пользователь импортирует одни и те же файлы в Framemaker (версия 10). Вид файлов CGM после первоначального импорта правильный. Однако если пользователь решит растянуть или сжать диаграмму CGM на странице, мы обнаружим, что:

  • 1) при сжатии - не только шрифт текста уменьшается пропорционально (как и ожидалось), но также уменьшается межсимвольный интервал (класс 5 CGM, элемент 13) и коэффициент расширения символов (класс 5, элемент 12). В целом, текст непропорционально сжимается по горизонтали.

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

Это похоже на ошибку в Framemaker. Однако у конечного пользователя также есть файлы, созданные третьими сторонами, которые правильно масштабируются. Мы скопировали функции этих файлов, в частности настройки:

version to: '1'
scaling mode to: ABSTRACT   
scale to 0   
using Text(class 4, element 4) in place of Restricted Text (class 4, element 5).

Мы также безуспешно экспериментировали с различными значениями межсимвольного интервала и коэффициента расширения символов (а именно, 1, 0 и 0,01). Как ни странно, для обоих этих элементов исходные файлы содержат значение «9.0E-44», которое представляет собой шестнадцатеричный код 0x00 0x00 0x00 0x40. Это выглядит как «значение секретного флага», но использование его в наших собственных файлах, похоже, не дает никакого эффекта.

Кто-нибудь знает значение этого флага и как его следует использовать?


framemaker
person Tony Eastwood    schedule 28.10.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Нам действительно удалось решить эту проблему. Похоже, что импорт FrameMaker очень специфичен и требует определенных жестко заданных значений для КОЭФФИЦИЕНТА РАСШИРЕНИЯ СИМВОЛОВ и МЕЖСИМВОЛОВ.

Что я пропустил раньше, так это то, что REAL PRECISION не был установлен на [0][9][23], как это было бы для поддержки хорошо известного формата с плавающей запятой IEEE, а на [1][16][16] - что является архаичный десятичный формат с фиксированной точкой. Возможно значение Hex 0x00 0x00 0x00 0x40. в этой кодировке имеет немного больше смысла (конечно, это все еще значение секретного флага!)

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

Я боюсь, что мы не экспериментировали, чтобы увидеть, будет ли «0x00 0x00 0x00 0x40» при повторном представлении в виде значения IEEE продолжать работать, если мы установим REAL PRECISION обратно [0][9][23]. Мы были так рады, что нашли способ обойти эту ошибку FrameMaker!

person Tony Eastwood    schedule 14.11.2011

arrow_upward
0
arrow_downward

В спецификации нет значения секретного флага, в спецификации ISO 8632-3 упоминается, что и КОЭФФИЦИЕНТ РАСШИРЕНИЯ СИМВОЛОВ, и МЕЖСИМВОЛОВНЫЙ МЕЖДУНАРОДНЫЙ интервал являются реальными значениями. Значение HEX, которое вы видите, просто означает, что значение почти равно нулю.

Хотя значение CHARACTER SPACING имеет смысл быть близким к нулю (из спецификации):

МЕЖСИМВОЛОВ: определяет количество пробелов, добавляемых между символами в строке;

на самом деле это не для ФАКТОРА РАСШИРЕНИЯ ХАРАКТЕРА:

Коэффициент расширения символа определяет отклонение отношения ширины к высоте символа от соотношения, указанного разработчиком шрифта.

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

person ph8c4    schedule 10.11.2011