Question

我们有直接编写CGM（或交互式WebCGM）文件的代码。我们可以完全控制所有的CGM基元，并可以根据需要生成版本1,3或4个文件。一般来说，我们编写的CGM在各种行业标准渲染器（MetaWeb，SDI，ISoView等）中完美呈现 - 这些渲染器允许我们无缺陷地缩放，平移或缩放。

不幸的是，当最终用户将相同的文件导入Framemaker（版本10）时，我们遇到了问题。初始导入后CGM文件的视图是正确的。但是，如果用户选择拉伸或缩小页面中的CGM图，我们会发现：

1）收缩 - 不仅文字字体按比例减少（如预期）但字符间距（CGM class 5，element 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”，即Hex 0x00 0x00 0x00 0x40。这看起来像'秘密标志值' - 但在我们自己的文件中使用它似乎没有任何效果。

有谁知道这个标志值的重要性以及它应该如何使用？

Answer 1

我们确实设法解决了这个问题。看起来FrameMaker导入非常具体，并且需要CHARACTER EXPANSION FACTOR和CHARACTER SPACING的某些硬编码值。

我之前错过的是，REAL PRECISION没有设置为[0] [9] [23]，因为它将支持着名的IEEE浮点格式，但是[1] [16] [16] - 这是一种古老的“固定点”十进制格式。也许值Hex 0x00 0x00 0x00 0x40。在这种编码中更有意义（当然它仍然是秘密标志值！）

完成此操作后，文件成功导入FrameMaker - 当它们被展开或缩小时，文本的行为与在任何其他渲染器中的行为完全相同。

如果我们将REAL PRECISION设置为[0] [9] [23]，我恐怕没有尝试查看'0x00 0x00 0x00 0x40'，当重新表示为IEEE值时将继续工作。我们对这个FrameMaker漏洞找不到任何方法感到宽慰！

Answer 2

规范中没有秘密标志值，ISO 8632-3规范提到CHARACTER EXPANSION FACTOR和CHARACTER SPACING都是实际值。您所看到的HEX值仅表示该值几乎为零。

虽然CHARACTER SPACING值接近于零（从规范中）是有意义的：

CHARACTER SPACING：确定字符串中字符之间添加的空白量;

它不适用于CHARACTER EXPANSION FACTOR：

字符扩展系数指定字符的宽高比与字体设计者指示的比率的偏差。

规范的附录D并没有真正说明如何处理扩展的零值，因此每个解析器都可能以不同的方式处理这种情况。