When using the document map in AE 5.4, I thought that there used to be a way (shortcut key?) in older versions of Arbortext to collapse a entire 'level' of a document (not the whole doc), rather than trying to do it using the select 'all' in the tags dialog box of 'Collapse / Expand Divisions.'
Case in point - (large docs of 1000+ pgs) After I do some raw XML editing and update the doc, it reopens with every single tag expanded fully (arrggh). Which means that, to again make it reasonably manageable for normal navigating, I've got to manually go through it and close down the sections until it is organized in a less user 'hostile' way (by Chapter and Work Packages).
Didn't there used to be a way that you could do some mouse or keyboard action over the vertical lines of the doc map and close it down by 'levels' rather than by discrete tag names?
Curious - maybe I'm just engaging in a little late summer, Labor Day Friday, daydreaming with this one.
But if anyone has any appropriate tips/tricks for this, I'd appreciate a pointer.
Regards and hope you all have a nice last summer weekend,
Thanks - Simply having the shortcut key (Ctrl-Shift-'n') was enough (in fact, that was what I was trying to remember.)
A while back, I had our .dcf file 'tweaked' by Jerry at Arbortext. now they are consistent throughout our shop (all newbies except me, and they're just learning both XML and Arbortext, doing Army DoD LOGSA tech manuals), so as you might guess, I'm somewhat reluctant to go mucking around in there. But thanks for the insightful reply, nonetheless.
Another nice trick that works well in conjunction with "show fullkeymap" is "show aliases", which lists all the aliases defined in the current application (including the default OOTB command aliases). That can help you figure out what a command is, if it's not obvious from the name of the command. It is also useful (in conjunction with $ARBORTEXT/lib/dialogs/editwindow.xml) to figure out what commands get triggered by toolbar buttons.
We are having a problem with Print Composer not being able to find certain characters in font files shipped with Windows 7, versus what was shipped in Windows XP.
We are using Arbortext Editor 5.2 M051 with Print Composer. We realize that this version is not certified by PTC/Arbortext to work with Windows 7. Nevertheless, it seems to work just fine with the exception of this font file issue. Further, if the True Type font files shipped with Windows XP are installed over the version of that same font file on a Windows 7 machine, Print Composer will create the same Postscript on the Windows 7 machine as it does on the Windows XP machine.
For instance, the font file "Times.ttf" is version 3 in Windows XP and is version 5 in Windows 7.
Certain characters in this font, mostly ligatures such as "fl" and "fi", are undefined in the version 5 "times.ttf" file. That is, in the version 3 the "fi" is defined as both U+xFB01 (Latin Small Ligature Fi) and U+F001 (Private Use), whereas in version 5 the U+F001 definition is not listed. The default charent.cf defines "filig - - unicode 0xFB01 current ":fi", so it is not clear how this Private Use definition comes into play.
When Print Composer makes the PostScript file that is sent to the printer in Windows 7 using times.ttf version 5, it leaves these characters as undefined in the PostScript file. Acrobat Distiller/Adobe PDF doesn't do anything about this and therefore they are missing from the PDF output.
Does anyone have any solutions to this that involve customizing the Arbortext environment, such as modifying the charent.cf file or any other Arbortext Editor files?
Modifying the Windows 7 environment, such as replacing all the necessary fonts with the older version, is not an option for us.
Pay attention to whether or not you are using anything that will cause the pipeline to fire (profiling, DLM, etc.) as this can "disconnect" certain charent.cf mappings due to the multiple parsings. Note also that the premature application of the charent.cf (too early in the pipeline) may have been fixed since we had this problem which we resolved by using font specific elements with type attributes in order to ensure the stylesheet resolved this at the very last step of processing. For example: <arialms type="euro">
Finally, we had a font specifically required by The Powers That Be. It was not technically created correctly and some high values didn't map properly. Arbortext support used a tool, the name of which I no longer remember, to open, edit, and resave the font files for us (going above and beyond, I'm sure). It seems unlikely that the Windows 7 fonts would be "broken" but I can imagine that standards have changed or a new standard is being followed in the Windows 7 version of the fonts. It is conceivable, then, that it is not a "5.2 m051" problem, but rather a configuration "issue" you'd have to resolve even if you were using a version of Editor that did support Windows 7.
You might have some luck if you rebuild your font metric files from your new Windows 7 font(s). There is a utility called wsdk2afm.exe in the $ARBORTEXT/bin directory that will do this for you. Take the new font metric files you generate, and put them in $CUSTOM/fonts, and see if that clears up your problem.
I ran into a similar problem recently, which I never did get to the root cause of.
A customer of ours found that certain characters didn't get output by print composer. They seemed to think it was connected with the use of a graphic entity used for a symbol. They were using XP and Epic v5.3, but I couldn't reproduce the problem on XP or Win7.
In the end, I 'cured' the problem by turning off ligatures, using a .tmx file for the doctype. This file contained the line
The resulting output contained the 'fl' and fi' characters which had been missing, and didn't do any get violence to the format.
Adrian Jordin Senior Consultant
Mekon Ltd. Mekon House, 31-35 St Nicholas Way, Sutton, Surrey SM1 1JN.
Hi Ed, I dug up a few of our possibly related cases on ligatures. Here is the relevant "problem" statement regarding the font files we were using. For what it's worth. 😕
From 5172668: "...none of the bits in the header for Unicode ranges or Codepages supported are set in the TTF file. As a result, even though valid AFM and TFM files including the fi ligature character are made by fontconfig, preview still decides to do a character substitution because based on the "support codepages" setting, it thinks the ligature characters are not there, or that any character with an index beyond 255 for that matter."
Support edited our font files flipping the bits for Unicode and/or Codepages and we were on our way.
Subsequently, we discovered that PDFs generated using PDF Direct containing ligatures were not searchable on words containing the ligatures. SPR 1227509 provided a workaround ... a switch to disable ligatures ... sometime in the 5.2 release according to comments in our case. That said, the SPR indicates resolution in 5.1h but doesn't say anything about which 5.2 release. We used the following environment variable, added as a result of the SPR, in an ACL file in the PE (it might have been E3 still) ...custom/init folder:
$ENV["APTLIGATURESENABLED"] = "no"
Bad for typography, good for online use of PDFs.
There was a third case I looked at to remind myself of the charent.cffailing on the composition pipeline. That had to do with our trying to use character entities to hit specific glyphs in Zapf. There we had to resort to using element/attribute/stylesheet to get our output through the pipeline.