0

We have code that writes CGM (or interactive WebCGM) files directly. We have complete control of all theCGM primitives and can generate version 1, 3 or 4 files as required. In general the CGM we write renders perfectly in the various industry-standard renderers (MetaWeb, SDI, ISoView etc) - these renderers allow us to scale, pan or zoom without defect.

Unfortunatley we have an issue when an end user imports the same files into Framemaker (version 10). The view of the CGM files after initial import is correct. If, however, the user chooses to stretch or shrink the CGM diagram within the page we find that:

  • 1) on shrink - not only is the text font reduced in proportion (as expected) but the Character Spacing (CGM class 5, element 13) and the Character Expansion Factor (class 5, element 12) also shrink. Overall, the text shrinks out of proportion in the horizontal driection

    2) on expansion - all three of text font, Character Spacing and Character Expansion Factor increase - so text that was originally confined within a graphical box will now extended considerably beyond the right hand margin.

This looks like a bug in Framemaker. However, the end user also has files generated by third parties that do scale correctly. We have copied features of those files - in particular setting: 

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).

We have also experimented with various values for Character Spacing and the Character Expansion Factor (namely 1, 0 and 0.01) without success. Strangely for both these elements the original files contain the value '9.0E-44' which is Hex 0x00 0x00 0x00 0x40. This looks like a 'secret flag value' - but using that in our own files seems to have no effect.

Does anyone know the significance of this flag value and how it should be used?

Tony Eastwood
  • 781
  • 2
  • 9
  • 23

2 Answers2

1

We did actually manage to solve this problem. It does appear that the FrameMaker import is very specific and requires certain hardcoded values for CHARACTER EXPANSION FACTOR and the CHARACTER SPACING.

What I missed before was that REAL PRECISION was not set to [0][9][23], as it would be to support the well known IEEE float format, but to [1][16][16] - which is an archaic 'fixed point' decimal format. Maybe the value Hex 0x00 0x00 0x00 0x40. is a little more meaningful in this encoding (its still a secret flag value of course!)

Once we did this the files imported successfully FrameMaker – and when they are expanded or contracted then the text behaved exactly as it would do in any other renderer.

I'm afraid we did not experiment to see if the '0x00 0x00 0x00 0x40', when re-represented as an IEEE value would continue to work if we set the REAL PRECISION back [0][9][23]. We were just so relieved to have found any way around this FrameMaker bug!

Tony Eastwood
  • 781
  • 2
  • 9
  • 23
0

There is no secret flag value in the specification, the ISO 8632-3 specification mentions that both the CHARACTER EXPANSION FACTOR and the CHARACTER SPACING are real values. The HEX value you're seeing just means that the value is almost zero.

While it makes sense for a CHARACTER SPACING value to be close to zero (from the specification):

CHARACTER SPACING: determines the amount of blank space added between characters in a string;

it doesn't really for the CHARACTER EXPANSION FACTOR:

The character expansion factor specifies the deviation of the width-to-height ratio of the character from the ratio indicated by the font designer.

Annex D of the specification doesn't really say how to handle zero values for the expansion, so every parser might handle the case differently.

ph8c4
  • 96
  • 1
  • 7