Skip to main content
R
RobertWilliams1-Visitor
1-Visitor
September 2, 2011
Question

AE 5.4 Document Map Collapse Level

  • September 2, 2011
  • 12 replies
  • 2251 views
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



    12 replies

    Show previous replies
    E
    ebenton1-Visitor
    1-Visitor
    September 7, 2011
    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.
    N
    naglists1-Visitor
    1-Visitor
    September 7, 2011
    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.


    Terms & ConditionsAccessibility statement