Before you tell me, I know I can refresh the display - but I'm wondering if everyone has this issue and has learned to live with it, or it's something to do with my machine setup. As I've been asked to give advice on specifying a machine to work with FM, I want to check - although my machine meets (exceeds) the specs, the graphics card is basic...
I typeset a couple of journals in FM (programming journals, so the tool is appropriate for so many reasons).
I get the source articles in all sorts of ways (HTML, markdown, asciidoc, Word, OO...) and I tend to paste-special as text to get the articles in. I have to layout and edit/proofread, so it's as easy to format as I edit...
As you can imagine, the white-on-grey means I have to make any corrections to names one at a time, and keep refreshing because I'm effectively typing blind. This one isn't "occasionally" - it is every edit! (What it "should" look like on teh left, what I see while editing on the right.)
In the "text" examples, I start from the end of the article and work up as that way the corruption doesn't affect so much. It doesn't happen EVERY time, but does more than not... and if it happens with an article, it happens every edit within that article. (As before, a "what it should be" and a "what I see"...)
Is it just me? I feel I'm going to wear out Ctrl+L because I can be pressing it every few seconds!
Thanks in advance,
What version of FM? All patched up? Where are files located - local or on a network path? How's your machine stack up - memory, hard drive type, etc.?
Thanks for the reply, Jeff...
Windows 10 Pro 64-bit, fully updated.
Intel Core i7-3770 CPU @ 3.40GHz
All files local on a 500GB SSD drive (relatively new, but had same problem with old HDD).
FrameMaker 2017 - fully patched (but had the same problem with FM11).
File sizes relatively small - from 1 to 10 pages, and mostly text with a few anchored frames. BUT the problem appears often before I get much formatting done. The first pass following a paste of plain text... I don't recall having it happen much when typing (apart from the colour block issue of the white-on-grey) but deleting an empty paragraph mark makes it impossible to see where the cursor really is.
Graphics cards about 4 years old (I have 2, same card, as I run 3 monitors). Basic card - NVIDIA GeForce GT 520. It should be fine for what I'm doing - I don't need a high-end graphics card for interactive shoot-em-ups. BUT it's the only thing I can think of that *may* be an issue.
If it's an unusual problem, it's worth spending time investigating... but if it's a "Yeah, we all see that..." then it's an FM issue and I'll live with it. Ctrl-L only takes a split second. 🙂
re: As I've been asked to give advice on specifying a machine to work with FM, I want to check - although my machine meets (exceeds) the specs, the graphics card is basic...
We probably need a separate thread on how to spec an optimal FM machine, and I'll make some guesses below. I would expect, however, that almost any stable graphics (integrated or card) would be suitable. Even the lamentable Intel IGP should have adequate performance for desktop publishing. I only recently switched from AMD's AGP to a low end PCIe card because I plan to move to a 4K display, and I'm not sure the AGP can do that.
On the corruption, it's been my experience that when using reversed-out text, FM has always behaved this way, even on Unix. If it were a card, driver or OS problem, we'd expect to see it in other DTP and WYSIWYG WP apps. But if you're seeing it in normal black-on-white text in FM, that's something that needs resolving, and I have no guesses on root cause.
On the subject of an optimal FM platform, here's what Adobe says:
FrameMaker system requirements: FrameMaker (2019 release)
We need some input from the developers on whether FM2019 has become any more parallelized than prior releases, which weren't, to any great degree. Although now 64-bit, FM is probably still largely single-threaded - only heavily using one core at a time. A quad core CPU should be adequate:
1 core for FM rendering workflow
1 core for other user work whilst that is in progress
1 core for security nannyware
1 core for the Windows bloatware itself
Consider disabling multi-threading (Intel Hypethreading) to get full per-core performance.
Get a reasonably high base clocked CPU, 3.5GHz or above.
A new machine probably means holding your nose and getting Win10/64 Pro. Although you may yet be able to get a machine with Win7 downgrade rights, it's going off support in the near future.
8 GB RAM minimum. 16 is probably safer, but more than that seems needless unless your data object sizes get bigger than 8GB during edit or render.
Graphics for DTP is driven mainly by monitor requirements (resolution and interface). Integrated graphics and low-end card might not support much higher than full HD. Get something that specs at least DisplayPort 1.3 and HDMI 1.4, and explicitly specs 4K (both 3840×2160 and 4096×2160). 5K and 8K optional. Wide gamut and HDR probably of no benefit yet for FM.
Storage would be SSD of course. Spinners (aka rotating rust) drives are passé, other than for bulk storage. Spec an SSD with a generous and credible warranty, and a capacity that is 50% more than forecast life-cycle needs, so that it can be partitioned for generous wear-leveling over-provisioning (and thus long and reliable life). A motherboard with at least one M.2 slot is suggested for optimal performance and economy.
One way to work around the problem with corrupted text display on a coloured background is to set up the paragraph style with the font background colour set to the same as the grey background. This will prevent the white blocks hiding the white text as you type.
Sorry, but I have no idea what's happening with the overwritten text, I've never seen that before.
Thanks, Ian - I hadn't thought of this! It will save a lot of trial-and-error with correcting names.
That's a clever solution, Ian. I can definitely use it.
The effect of the text overlapping looks like there are two text frames above each other.