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?
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!