Adobe Community : All Content - All Communities

vs. in Variables

forums_noreply@adobe.com — Tue, 02 Sep 2014 16:27:42 GMT

Arnis: "The turning off of properties using the <Default ¶ Font> tag is probably a habit that goes back to some buggy behaviour in very early editions of FM where occasionally a specified character format would spill out of an x-ref (or was it a variable?). FWIW, it's easier and more convenient to use </> instead."

Is </> documented anywhere?

And is it identically equal to <Default ¶ Font>?

It would be nice to have a Variable construct that just means
</ChFmt> "terminate the most recent markup", rather than
<Default ¶ Font> "reset defaults for the remainder of the string to whatever para/char formats happen to be in effect."

For example, if doing an arbitrary 11/17 fraction in the pre-Unicode way as
<Superscript>11<Default ¶ Font><Symbol>\xa4<Default ¶ Font><Subscript>17
with a font override applied to the para, the denominator reverts to the Paragraph format and loses the override (yet another reason to avoid overrides, to be sure).

It is possible to create bookend Character Formats for some things, for example </Superscript> which is identical to <Superscript> except for the Superscript attribute, which is off for the </ version.

But it doesn't seem possible to do the same for a font tag like <Symbol></Symbol>. There is no undo for the font Family:, only an "As-Is" which unsurprisingly appears to do nothing.

This specific example is done much more elegantly with Unicode these days (often entirely without Character Formats), but there are doubtless other cases where a </ChFmt> tag would be useful.

FM 15.3 Survey Underway

forums_noreply@adobe.com — Tue, 04 Mar 2014 21:23:10 GMT

Just got an email with a unique single-use link. Just kidding about the 15.3. The actual term was more vague.

The choices to prioritize are a longer list than usual, and are re-ordered by you, and are apt to exclude all the things you care about .

There is a free-form field for stuff they neglected to ask. You might want to bring your Santa Clause list up to date in case you get the email.

I pasted in:

Cross-Reference by $MarkerText
Frame Anchoring Position: "Above Current Line"
SVG passed through as vector to HTML5, PDF, XML and other delivery formats that support vector - SVG is, after all, XML
Real endnotes
Bring Set_Monitor_Size into 21st century
Master pages of varying sizes, including
Height: [ Unlimited ]
Control-Click and shift-click multiple selection of non-contiguous paragraphs

ANSI Z535.1 Safety Colors in Frame

forums_noreply@adobe.com — Mon, 21 Feb 2011 15:56:11 GMT

Frame 7.1 Solaris (Frame 9 Win7 available).

Although the manuals I work on are print-published only in grayscale (600 dpi bitmap, actually), we make them available on the web as PDFs (which could be in color). At some point in the future, we may publish in color (probably using Xerox or HP laser engines).

For recent works, we've been using color, where convenient, and just leaving it enabled in the PDFs. For lack of a more compelling model, the color space chosen is sRGB. Those users exposed to color are most likely viewing the PDF on a computer, or printing it on their own inkjet or color laser printer.

A portion of the color content is graphic panels for DANGER/WARNING/CAUTION/NOTICE, and representation of product decals and labels of those same hazard classes.

The dominant market is U.S. domestic, so we follow ANSI standards for these admonishments. The ANSI standards include color specifications (ANSI Z535.1-2006) for safety notcies. The colors used in our manuals are only Red, Orange, Yellow, Blue at present.

Z535.1 specifies these colors in Munsell HVC and CIE 1931 xyY illuminant C coordinates. Most of the ANSI colors are out of gamut for sRGB.

The ANSI colors are realisable as printable spot colors on decals and product labels, but ANSI did not address how to render them in typical document printing. (Actually, the spec claims to provide Pantone equivalents, but does not.)

So, the spec colors can't be matched in normal printing from a random PDF viewer to a random color printer.

Well, we can at least pick something and be consistent, so the safety colors all have the same appearance within our documents, and perhaps match hue to safety spec.

Frame's color library, the Munsell Library of Colors or the Munsell High Chroma, has some of the Munsell values for ANSI patches, but they look awful, probably due to the [unspecified] choice of rendering intent in the mapping of library colors to the RGB/CMYK/HLS values actually used. And, of course, Frame has no color management to speak of, so the RGB/CMYK/HLS values are uncalibrated.

There may exist professional tables of Munsell/sRGB matchings (rit.edu's Munsell lab seems to have misplaced theirs during their web revamp), but this has a similar problem: what was the rendering intent during the mapping? Typically, conversions try to preserve some color difference between nearby out-of-gamut colors. I don't care about that. I want to get as close as possible to the ANSI colors in sRGB space, and I want to at least match hue (no "blue turns purple").

Any number of web sites purport to have RGB values for these colors, but they are even more vague about how they arrived at them, so they usually disagree from one site to the next.

There are lots of tools that perform CIE to sRGB conversions, but they are similarly challenged in the matter of intent (plus whether they accounted for the wandering of hue as you attempt to scale chroma in models other than Munsell).

What I probably need is the limiting sRGB value of the same hue as the Munsell value for the ANSI spec color.

Using BabelColor, I experimented with sRGB values until I could obtain:

* a match for the Hue

* a match (or a within-ANSI-tolerance) for Value.

* as close as possible for Chroma.

What I came up with is at the end of this post.

These colors will be entering the manuals as objects from Photoshop and Illustrator primarily, typically RGB EPS images, tagged as sRGB with embedded profiles. Some might be created in Frame directly, and as long as:

"Tag Everything for Color Management"

with a working space of:
sRGB IEC61966-2.1

is specified during Distiller, the resulting colors in PDF seem to match regardless of source.

What is everyone else doing about this?

Z535.1.Blue _________________
ANSI Munsell: 2.5PB 3.5 / 10
Nearest sRGB: 2.5PB 3.5 / 7.9
RGB(255):     000   089   137
RGB(100%)     0.0 34.9 53.7

Z535.1.Orange ________________
ANSI Munsell: 5.0YR 6.0 / 15
Nearest sRGB: 5.0YR 6.0 / 12.7
RGB(255):     222   125   000
RGB(100%)    87.0 49.0   0.0

Z535.1.Red ___________________
ANSI Munsell: 7.5R 4.0 / 14
Nearest sRGB: 7.5R 4.0 / 13.6
RGB(255):     187   039   036
RGB(100%)    73.3 15.3 14.1

Z535.1.Yellow ________________
ANSI Munsell: 5.0Y 8.0 / 12
Nearest sRGB: 5.0Y 8.1 / 11.6
RGB(255):     239   203   000
RGB(100%)    93.7 79.6   0.0
_______

Values harmonized for ISO 3864-1:2002 would be nice too.

FM, TC, CC Cloudy Crystal Ball

forums_noreply@adobe.com — Mon, 08 Jul 2013 11:52:07 GMT

Needing a new version of FM and Acrobat at least, and wanting a credible path to HTML, and probably ebook, which implies RoboHelp, I'm looking at getting a retail copy of TC4 for home use. An upgraded Illustrator is fine too.

The TC4 bundle is a more attractive deal than parts-is-parts, some of which may be locked in the cloud now anyway. The rest of the TC bundle is not compelling.

The TC4 versions of Acrobat (X) and Illustrator (CS6) are not current. Acro is now XI and Illustrator is now version "CC". The vintage doesn't bother me so much as what that anachronism implies.

My guess is that TC4 is unlikely to be upgraded to bundle newer versions of anything now imprisoned in the cloud. Anyone have alternative insights?

FM and RH are not presently available via cloud, only via classic perpetual licence. But I'm thinking that unless CC becomes a bigger cloudburst than it has already, Adobe will eventually consign all products to that time-bombed gulag in the sky. Any guesses on when this might happen?

And any guesses on how much longer retail TC4 will be available?

Replies counted but not served today.

forums_noreply@adobe.com — Tue, 04 Jun 2013 15:06:12 GMT

Anyone else experiencing this?

And please respond only if you are, because I may not be able to read replies.

For example:

Subject: half-hearted Exclusion <g>

Replies: 7

Within the last hour, when I click on the thread, the site is only serving the basenote and 2 replies.

And as we know, Adobe has no means to report web problems.

Switched or Conditional Page Size

forums_noreply@adobe.com — Wed, 01 Jun 2011 21:10:57 GMT

Some recent work has involved manuals for export products, and the issue of page size could be on the horizon. We presently render to US letter size (USL), but A4 might become needed ...

... ideally from a common shared set of book files ...

Content scaling is not an option, as some graphics are 600 dpi bitmap. optimized for our 600 dpi pub engine, and they develop visible artifacts if
rescaled.

The USL page layout contemplated this possibility way back when, so we have a column layout solution that allows keeping the same column and gutter sizes, yet leaves ample margins for printing and hole punching on USL or A4.

The content already re-flows onto the taller A4 page with no particular difficulty. And it does reflow, because condition codes switch some content on and off depending on target English-speaking market. Update Book is required in the workflow already.

The issue is how to quickly switch between USL and A4 page layouts.

FM 7.1 does not have conditional page layouts, and it's not clear if later versions (we do have FM9) have anything comparable.

Two workarounds that come to mind are:

Create (one time) two separate sets (USL and A4) of empty book component files, used only as the source for Master Pages.
Workflow:
Open each book component
Import MPs (Master Pages)
Set Condition Codes
AMP (Apply Master Pages)
Update Book
Print
Rinse and repeat for other page size
Create (one time) a single separate set of empty A4 book files, used only for printing. These call in the entire Flow A of the USL files content as Text insets imported by reference.
Workflow:
Open A4 clones
AMP
Update
Print

_______

Any other ideas?

Enter Unicode U+21CC code point in dialogs?

forums_noreply@adobe.com — Thu, 26 Jul 2012 18:17:37 GMT

Is there a backslash notation?

This question would only apply to FM8 or later.

I only have FM9 to try things on.

When using special (non-keyboard) characters in the Unicode age, it is often the case that one discovers the needed glyph on some Unicode web site, and is then armed with the code point, but not necessarily a glyph that can be copied and pasted.

Unicode-aware versions of FM include an unpleasant little Character Map, and there is also, on Windows, the system Character Map (which allows entry of code point numbers, or search by formal Unicode glyph id).

Yes, there is also a way, on Windows, of entering Alt+21CC code points, but this requires a Registry hack and a reboot.

It appears that the only way to enter Unicode characters in Frame is:

via the FM Cmap,
pasting from the OS Cmap or some other source, or
using the numpad Alt hack.

If creating a Variable for a special character (commonly needed because a Unicode or more fully populated Unicode font is required), it has to be Cmap'd, Alt'ed or pasted in the Variable dialog. There is, so far as I've been able to discover, no:

\u+21cc

style notation for entering known code points as plain text. There is apparently no Unicode equivalent to the legacy \xb4 notation for special characters.

I've studied the MIF for one of these, and was surprised to see that Adobe is apparently storing the actual UTF16 in the definition, and in body text when typed directly into Flow A. If you hack MIFs with an editor that is not at least UTF16-safe, beware?

Is that about it?

FM11: Is my favorite :( bug fixed ?

forums_noreply@adobe.com — Tue, 24 Jul 2012 17:54:40 GMT

This thread is for logging questions and answers on this topic.

Please confine the bugs to those easily reproduced, and those with Adobe trouble ticket numbers (assuming Support does that).

Let me start with one of mine:

Q: Do cross-reference markers in a Table survive Sort in FM11?

A: ?

This ancient bug, probably as old as Table Sort itself, was still not fixed in FM10. The sort is apparently done by copy, paste & delete, rather than cut & paste, and Xref markers are lost during paste.

I don't have a machine I can do a trial install of FM11 on, or I'd test it myself.

Community Help

forums_noreply@adobe.com — Thu, 02 Feb 2012 17:59:38 GMT

Arnis, you probably need to completely delete that "Preparing documents for accessibility" CH thread, rather than just lock it.

My response and your response (but, curiously, not the empty basenote), show up as discussion on the referenced Help page.

I also see apparently active Reply links there, with no indication of locking (and I don't plan to test them).

Is this a broken Help feature that accidently got turned on/discovered, or is it expected that, once debugged, users will be able to initiate and/or respond to discussions from Help pages?

It could turn out to be a handy way for users to clarify or expand upon Help content.

It could also cause Help pages to get cluttered with the sort of topic drift that is all too common on the internet (particularly if forum users don't realise that their responses are logged elsewhere). Presumably some web wardens will keep an eye on it.

Title/Heading/Row-Align Multi-Column Tables

forums_noreply@adobe.com — Sat, 28 Jan 2012 19:35:48 GMT

File under: Frame Annoyances, with a limited hacky work-around

In the two-column format we commonly work in, we often need a table that is column-wide, but may flow into multiple colums.

The problem is that the continuation heading (and TableTitle, if used), never align with the starting heading/title. This is because the continuations start at top of column, whereas the table itself starts (by "Anywhere" default) below the anchor line (presumed to be "In Column" for this discussion)..

OK, what if we change Table > Table Designer [Basic] Start to:

Top of Column: Oops, that becomes top of next column, leaving the anchor text column-widowed (but it gave me an idea).
Top of Page: Oops, that becomes top of next page, leaving the anchor text page-widowed.
Float: No effect

OK, what if we change the anchor text Format > Paragraph > Para Designer [Pagination] Format to:

[Pagination] Across All Columns (AAC): Oops, table appears only in left column on all pages, or;
[Basic] Space & Line Spacing, including negative values, appears to have no effect. Using a tiny font only minimizes the problem, and doesn't cure it.

I thought I had figured out how to solve this at one time, but could not recall it. I'm posting this in part to solicit some simpler solution. Web searching found only one solid candidate solution, and it was, of course, 404. Perhaps Frame versions later than the FM7/Win and FM7.1/Unix that I routinely use have enhancements to address this.

We normally just sidestep the problem by using an AAC format and a table that spans the page, with a fake center gutter, simulating a multi-column flow. But in a recent case, I wanted a real single-column-wide table of variable length (due to conditional rows and expected future growth), but I wanted the headings to align across columns. The table did fit on a single page, which is a limitation of the following hack.

Hack: This example presumes a normal 2-column page text frame that is 7.5in wide with a 0.24in gutter (3.63in columns), and table that needs no more than one page. It works for 3- and 4-column layouts as well.

Use an AAC anchored frame text line.
Create a full page width (7.5in) anchored frame (which can be Below, Top of Col, as desired).
Create a text frame inside the anchored frame. This frame is:
one more than your standard page (3-column for this example)
Same gutter size (0.24in for this example).
Initially draw the text frame to fit inside the the anchored frame, so you can easily grab it.
Make sure the default (anchored table) paragraph format of the first column is "In Column".
Use Graphics > Object Properties to adjust the inside text frame:
Set Width: to your standard text frame total width plus 1 column and 1 gutter (11.37in for this example).
Set Offsets: to 0 and 0 (this will push the rightmost column out of sight for the moment).
Insert your table at the anchored table text of the inside text frame.
In Table Designer, set Start: to Top of Column (this pushes the start of table to column 2).
Select the internal text frame again.
Set Offset From: Left: to negative one column + one gutter (-3.87in for this example).
The table now appears to start in page column one, and flows to additional columns with heading alignment.

This worked perfectly for my recent requirement. In fact, I used a 3-column layout (4 actual) for the text frame inside the anchored frame. Some math is required, sorry .

Framemaker Competitive Comparisons ?

forums_noreply@adobe.com — Mon, 12 Dec 2011 11:58:48 GMT

Are there any current sources (Adobe or not) comparing Frame to contemporary tech pubs solutions?

A casual google turns up some hits, none recent, and some seriously outdated (1999).

I'm particularly interested in FM vs. Arbortext, because I suspect that it may be being pitched to management, unbeknownst to the Tech Pubs Dept (a standard PTC tactic, I hear). Since AT is focused on a structured XML environment, this question perhaps belongs in the Structured forum, but we are presently an unstructured shop, and would need to assess any such transition from that point of view.

I see basically zero competitive info on the Adobe FM product pages. I'm wondering if this is due to lack of marketing resources to create the content, because the pro-FM story isn't necessarily compelling, or just because Adobe likes to pretend that there is no competition.

The recent, and so far lackluster "Dispelling some myths on FrameMaker" is also missing the mark. It so far reads like those "get the facts" web sites that politicians put up, filled with non-denial denials and providing hard-hitting answers to unasked questions.

Non-Breaking Hyphen in MIF String ?

forums_noreply@adobe.com — Tue, 01 Nov 2011 17:01:56 GMT

I'm using a spreadsheet (LibreOffice Calc) to generate the MIF for a Framemaker table: Paste in lines of tab-separated part_numbers and descriptors, copy out raw MIF that opens in Frame as a 3-column table with callout#, part_number and descriptor, each having a unique Xref Marker with marker text based on the p/n & descriptor. It works (including escaping any Frame-special chars in the descriptors), except for one extra feature I'd like to have.

I'd like to make all dashes in the part-numbers into non-breaking hyphens (\x15). Using the Calc function SUBSTITUTE, I can change any character to any arbitrary string. Part numbers may have zero or more dashes.

So for raw string 123-456A, where "-" is an NBH, I'd generate:

According to the MIF(7) reference, either of these MIFs should work:

They don't.

They both throw a parsing error on open in Frame.

This doesn't work either:

It ends up as a literal \x15 in the final table.

This Calc function doesn't work either (where decimal 21 is hex 15):

=SUBSTITUTE($RawData.A3;"-";"CHAR(21)")

The character doesn't survive copy and paste through a plaintext editor, even if a raw 0x15 is valid MIF (which it may not be).

This is FM7.1 Unix, so I can't use the Unicode code point for an NBH (this is the suggest route for MIF8 or later).

The following MIF is valid, but may require more parsing of my strings than I care to invest in:

I could use:

=SUBSTITUTE($RawData.A3;"-";"'><Char HardHyphen><String `")

If I were sure that no partnumbers began or ended with a dash.

_______

Any other ideas?

Search Appears to Work Now

forums_noreply@adobe.com — Sun, 18 Sep 2011 14:11:29 GMT

So try it before suggesting that people use the Google trick.

I was wondering if that would be part of the 4.5.6.3 Jive upgrade.

And I see a dialog for tags. Cool.

Unable to change text color (from Black)

forums_noreply@adobe.com — Thu, 08 Sep 2011 16:34:15 GMT

For the next person who blunders into this and searches for an answer...

If you have a Condition Code whose decoration is a custom color, and you delete the color, the text goes to Black, and you cannot change the color of text bearing that CC - with local color override, or a Character Format that applies a color (I didn't try Paragraph format).

I am copying formatted content in from an older document that doesn't conform to current templates. I had deleted unused colors in the source, but not unused Condition Codes, one of which rode in with some text. What was controlled by the CC in the old doc is now controlled by a color Character format, except that when applied, the text stayed stubornly black (until I nuked the CC).

after text inset

forums_noreply@adobe.com — Wed, 24 Aug 2011 14:36:02 GMT

I'm spinning off versions of some manuals for another division (same product, different paint), and decided that rather than entirely clone parallel FM files, I'd try having the main Flow A be a text inset from the defining instance of the product manual, with division-specific content controlled by Condition Codes. Grave warnings on this forum to the contrary notwithstanding, it works perfectly . But I did run into an oddity while testing.

The clone manual started as a whole-flow paste of the defining content. When I began to test doing it as an inset, I deleted the clone Flow A, which had a Heading1 as the first Paragraph Format. This left an empty Heading1, into which the defining flow was imported, as:
<*> Body Page Flow [ A (Main Flow) ]
<*> Retain Source's Formatting
<*> Automatic

Alas, there were two extra empty pages at the end, due to the Heading1 having Top of Page elected, and due to Make Page Count Even on save.

So I deleted the inset and tried to change the Heading1 to Body.

No go.

I could insert or delete text in that Heading1 (so it wasn't set to read-only), but nothing would change the Paragraph Format.

So I saved it as a MIF. I found these tags:
<Para
<Unique 5547797>
<PgfTag `Heading1'>
<Pgf
   <PgfLocked Yes>
> # end of Pgf
<ParaLine
   <TextRectID 80>
   <String `'>
> # end of ParaLine
> # end of Para
> # end of TextFlow
# End of MIFFile

I've never noticed tag PgfLocked before.
And if you import the inset with
<*> Reformat Using Current Document's Formats
tag PgfLocked is not there.

Changing "Yes" to "No" (MIF hacking) fixed the problem.
Is there a Frame menu item for this? (this is 7.1/Unix)

I'm guessing that specifying:
<*> Retain Source's Formatting
is what's causing the lock.

Character Formats showing up in TOC

forums_noreply@adobe.com — Tue, 19 Jul 2011 16:05:10 GMT

TOC entries for, say, "Heading4", are nominally controlled by the paragraph format of the generated "Heading4TOC" format.

Sometimes the body narrative will have local mods to the Heading4 text. Depending on what you're doing, you may want those mods to show up in the TOC, or you may not. In my case, I did not, and was surprised to see a TOC entry show up in color.

It turns out that if you apply a Character Format to text used for TOC (and perhaps IX, LOF etc) generation, that ChrFmt is retained when rendering the TOC.

So if you want the local enhancement to appear in the TOC, use Chr Fmt. I verified this by setting a heading word to Character Format "Symbol" (which applies the Symbol font`, all else As-Is). The TOC entry had that word in Symbol glyphs.

if you don't want the local enhancement to appear in the TOC, use local overrides. I verified this by just doing a Format > Font > Symbol on the same word of the heading. The TOC entry had that word in roman.

_______

In my case, I have a table imported (as EPS) from a spreadsheet. I want the table title to appear in TOC, but of course Frame can't "see" that text. So the anchor line is that title in Heading4, which does appear in TOC. This particularly H4 has a local color override that is set invisible via Color Views. I want the TOC entry to be visible, but the Heading4 text in the body to be invisible. This works if the Heading4 has the invisible color applied with the graphics tools. It doesn't work if I use an invisible text Character Format.

Another way to hack this particular problem is to put the Heading4 title in a text frame behind the imported image. Then it requires no character formatting magic. But you can't see it during edit, and you need to hope that the table white fills really are, and aren't just transparent.

\x3c and \x5c in Variables

forums_noreply@adobe.com — Fri, 29 Jul 2011 14:42:52 GMT

Help advises us that if we want to use angle brackets ("<" or ">", although only "<" seems to matter) in a Variable definition, we should prefix (escape) them with a backslash ("\").

Help fails to advise us that the same is true for backslash itself, and further, that typing either "<" or "\" via their \x## hex codes can trip you up.

I wanted to create a var for the symbolic "therefore", the 3-dot triangle.

With a Character Format of Symbol defined,

I entered the definition:

<Symbol>\x5c<Default ¶ Font>

but when I hit [ Insert ], what I got was "<Default ¶ Font>" in Symbol font.

Frame had silently changed the "\x5c" to "\",

definition now: <Symbol>\<Default ¶ Font>

treated the resulting character as an escape of nothing in particular,

and then ignored it altogether.

I had to go back and revise the var def to:

<Symbol>\\<Default ¶ Font>

The same thing (symbolic <Default ¶ Font> result) happens with

"\x3c" for "<",

but not with "\x3e" for ">".

When a hex code is a printable latin character, Frame automatically converts it to that character when creating or editing a Variable definition. It neglects to advise you about this, and more egregiously, neglects to follow its own special character rules, but enforces the rules anyway.

fmprintdr.ps: Cannot finish printing.

forums_noreply@adobe.com — Wed, 29 Jun 2011 16:23:19 GMT

Searching the entire web didn't turn up this one, so let me add it here for reference.

I was printing a book from Frame 7.1 (xm7.1b023) on Solaris SPARC 64-bit. This book contained, amoung other things, about 100 EPS screencap images totalling 2.7GB.

I was watching the .ps temp file grow from another machine, and just as the file size reached 2 GBytes, it vanished.

Back on the Unix workstation, the terminal window displayed:

fmprintdr.ps: Using /opt/apps/frame7.1/fminit
fmprintdr.ps: Cannot finish printing.

My conclusion is that 32-bit versions of Frame (which FM7.1b023 presumably is), cannot handle Postscript output files larger than 2GB. This could also be an artifact of the execution environment that 64-bit Solaris provides for 32-bit apps. The file system APIs are likely 32-bit limited, and apparently signed.

I wouldn't be surprised if this 2GB limit applies to .pdf print files and .fm component files as well, although they are unlikely to ever get as large as .ps files commonly do. I would expect this limit to be common to all 32-bit versions of Frame running on any 64-bit OS. You'd expect a 2GB limit for 32-on-32, and I'm not terribly surprised to see with 32-on-64. I was hoping for an unsigned 4GB limit.

The second work-around, which worked, was to batch re-sample the original PSD images to EPS files at the actual rendering res. That got the .ps file size down to under 800MB.

_______

The first work-around, which did not work , was to open the book in FM9.255/Win7-64. That didn't even begin to generate a .ps file. It just silently did nothing. Since we'll eventually end up on this platform, I suppose I'll have to figure out what the problem is, and I can think of several matters to rule out.

Legacy Frame fonts for newer Frame versions

forums_noreply@adobe.com — Fri, 10 Jun 2011 19:21:30 GMT

Adobe apparently changed the fonts included with the product at some time after FM7.

Of the legacy fonts, we use Courier, Helvetica, Symbol, Times and Zaph Dingbats.

Looking at the FM10 product page FAQ, I see that Helvetica, Times and Zaph Dingbats are not there.

As the company adds seats, they may be Windows, and get FM9 or 10. These folks need to have full import and export interoperability with the FM7.1 seats on Unix.

One of these users just emailed me: hey, I seem to need Helvetica.

My research on this suggests that the safest FM9 or FM10 font solution (until we all move off FM7) is the Adobe "Type Basics" package ($99), which although a deprecated Type1 product, is still available, and contains everthing we need. Can anyone confirm?

I hesitate to suggest using a newer OTF or Unicode font to solve this problem, for several reasons:

Font names may vary slightly from what's in legacy docs (Helvetica Neue v. Helvetica).
Even if we don't venture out of legacy Western Latin characters, the OTF and or Unicode versions may have some glyphs not present in the Type1 fonts used elsewhere. And this might cause subtle problems, like just affecting one ligature sort of stuff.
Using a Unicode font in an FM9 or FM10 document might even cause its MIF to have major issues when back-ported to FM7.

Document (.fm) opens slowly. Gets worse over time.

forums_noreply@adobe.com — Thu, 26 May 2011 16:10:29 GMT

A co-worker just ran into this one. A book component file that should have opened in seconds was taking five minutes, and taking longer after every save.

After ruling out import problems, I saved out a MIF and scrolled through it looking for anything odd, and found it - a repeating string in an Xref.

There were callout text frames in a figure with circular cross-refererences to each other. One of them was apparently supposed to be "1" with a Marker, and the other just an Xref to it by text. At some point someone had changed the original marked text to an Xref to the other Xref (or possibly to itself - Frame was so unresponsive when attempting to diagnose that we just had to kill the process, reopen, delete the entire callout flow and fix it).

The displayed text was now "111111..." and apparently growing with each open/save cycle. Frame evidently doesn't detect this type of circular reference.

The only visible indication during edit was the subtle "____" at the bottom of the callout text frames, indicating text that has flowed out of sight.

Although I wouldn't expect a DTP application to have sophisticated loop detection, it would be nice if Frame could search for text frame overflows, if not hidden text generally. Frame obvious detects it, because it sets the frame border solid.

_________

A text inset containing a text inset is probably also fertile ground for runaway recursion.

Color Views Common Conventions?

forums_noreply@adobe.com — Wed, 13 Apr 2011 16:15:21 GMT

Arnis Gubins: ... so that the "Invisible Text" is seen in (say) View 6 and set to "Invisible" in View 1 ...

It appears that CV (Color Views) does indeed work for three main elements we need to twiddle in every document:

authoring-only information (Invisible for all publication modes)
masking graphical elements (Cutout for all publication modes)
web nav (Invisible only for print publication)

So the question arises, what standardized Views to use. If a random CV-aware Frameuser took over these documents, what "best practices" might they expect to see?

My inclination is to use:

Web publication
Print publication
<reserved for future use>
<reserved for future use>
<reserved for future use>
Authoring/draft mode

What say ye?

Table Sort Deletes Xref Markers

forums_noreply@adobe.com — Sat, 19 Mar 2011 15:17:37 GMT

FM 7.1 (Unix), and just seen in a test using FM9 (Windows 7).

If you have a table with Cross-Ref markers in it, and you sort the table, and Frame finds anything to sort, the markers vanish. Any chance this was fixed in FM10? Or is there some trick I don't know about?

My guess is that Frame's table sort is being done as a Copy-Paste-Delete, rather than by Cut-Paste. Cut typically preserves any Xref markers in the text. Copy typically does not (evidently to avoid ambiguous duplicates).

For narrative discussion of components, we use one or two appendix or reference page tables with a column for call-out number* (an auto#), SKU, and formal database descriptor (as we may need any combination of these elements). Each cell is tagged with a marker of type Cross-Ref, containing the table ID, column ID, SKU text and descriptor text. This creates a nice pull-down menu of SKUs in Special > Cross_Reference.

These tables are often created incrementally, adding parts as needed. To avoid adding parts already present, the tables are kept in sorted order. So new entries have to be entered manually at their relative table rows, because table-sort nukes the markers.

______

Edit: This issue has been known about since FM5.5. It apparently affects only markers of type "Cross-Ref". Temporarily renaming those (a MIF hack) insulates them from sort destruction, after which you need to rename them back. That's inefficient for just adding few new rows. It might be worthwhile where an entire existing large randomized table needed sorting.

______

* yes, we could combine the c/o# with another column.