AE 5.4 Document Map Collapse Level

[RobertWilliams]

Hi All,

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,



Bob Williams

Bristol RI

[ClayHelberg]

Hi Bob-



I think what you're looking for is Ctrl-Shift-n, to collapse to the n-th
level, e.g. Ctrl-Shift-2 collapses everything below the 2nd level.



For future reference, you can see what operations are mapped to which
shortcut keys by typing "show fullkeymap" at the Arbortext command line.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[SindyYoung]

Robert,
The levels/divisions you can collapse are set up in your .dcf file. You can take it all the way down to the para level if you like.
Hope that helps,
Sindy

[RobertWilliams]

Sindy,



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.



Regards,



Bob Williams

TRG Inc.

[SindyYoung]

I learn something new every day. I was unaware of the two commands Clay just talked about. Thanks Clay

[ClayHelberg]

You're welcome. 🙂



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.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[naglists]

Relatedly:

response(menu_cmd("File.Publish"))

Or any other menu tree will provide the alias / command behind a single menu
item (PTC's or your own).

[ebenton]

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.

[naglists]

No Windows 7 specific experience.

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.

[ClayHelberg]

Hi Ed-



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.



--Clay



Clay Helberg

Senior Consultant

TerraXML

[ajordin]

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

\ligaturesenabled=0

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.

[ebenton]

Thank you. This seems like a pretty good "brute-force" way of solving this.

We may also try Clay Helberg's suggestion of rebuilding the font files and putting them in the $CUSTOM/fonts folder.

Thank you to all who have answered so far.

[naglists]

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.