0

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

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

  • 1) 缩小 - 不仅文本字体按比例缩小（如预期的那样），而且字符间距（CGM 类 5，元素 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。这看起来像一个“秘密标志值”——但在我们自己的文件中使用它似乎没有效果。

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

4

2 回答 2

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 错误的任何方法让我们松了一口气！

于 2011-11-14T12:51:10.070 回答
0

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

虽然 CHARACTER SPACING 值接近零是有意义的（来自规范）：

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

它并不是真正的 CHARACTER EXPANSION FACTOR：

字符扩展因子指定字符的宽高比与字体设计者指定的比例的偏差。

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

于 2011-11-10T10:51:38.830 回答