There is of course a bunch of ways how you can screw up your fonts if you merge RT items (coming from different source documents) in any conceivable way. I have not come up with a universal solution yet - the best is to directly muck with CD structures and do all the font handling yourself.
The next closest solution that I’ve played with, is the use of DXL export, XSLT transform, re-import, that has the advantage to convert all fonts into plain text font names that should be imported back smoothly.
“Should”. The 1st thing, you have to remove $Fonts item after DXL export+transform, but before import (assuming you import it back into in one of your source documents)
After that it kind of works, but for some reason I still end up with somehow strange result that $Fonts contain the same font twice (it might depend on how I write XSLT, but I haven’t figured yet what exactly causes this).
Say I end up with the font id5=Arial, id6=Arial, id7=Windgings, etc. And in the same way in my RT some Arial text is marked to use id5 and some id6. This far no real problem as all shows up nicely.
Now if I edit and save this document - there comes a rub. A subtle one. Notes does the clean-up and removes the extra entry in $Fonts, so I end up with id5=Arial, id6=Windgings, etc. And it cleans up the rest of RT, so it still looks good. That provided my RT field is editable.
And in my application this field should not be editable (but the form should be in edit mode). I’ve tried to use an editable field in a restricted access section, that bypasses problems linked with the use of a computed RT field, but in this particular case it still causes a screw-up. Notes “fixes” $Fonts item, but obeys restriction on edit-ability of the field and does not modify the RT fields itself.
So parts of my text in Arial that used font id6 are now displayed in Windgdings. This causes certain readability issues.
I imagine that something like writing a code that opens the doc with a form using editable field, saving (so Notes clean up the fonts), then re-opening with the form that uses the same field in the “restricted” section might help. Clumsy, but is there a better solution somewhere along the way?
By just making the sections editor list in some way computable and changing the parameters I did not manage to make it editable on the fly - if it’s not editable when the form opens it rests non-editable no matter what.
Any bright ideas, suggestions?