Motion exports wrong font weight?

I've run into the problem myself. I can offer opinions as to why, but they'd just be guesses.

My solution was to reselect ALL the text from the Text box and reset the font by switching to another font then back again (and then reformatting what I wanted). If you have other formatting variances (kerning, tracking, etc.) in specific words, that may make new nodes,etc. In my case, it's usually been these formatting nodes that have been problematic, particularly if I've done something to a specific word and then have tried to undo the formatting to that same specific node (e.g.: setting a bold word within a text and then changing my mind and unsetting the bold on that word again. When going to render, the bold would show up again in the render. I think the switch to another font for the entire selection trick clears out any superfluous nodes that might be residual.

(How I see it:

when unbolding a word should revert back to the original node, but it doesn't, it creates another level of inner nodes instead. If this happens, it's necessary to select through what would become the node boundaries and use the technique to reset nodes [sorry, I don't know how else to explain this.] Maybe you can see how the rendering process can mistake the boundary especially if it thinks that TextEdit should have cleared the boundary. It's obviously a bug that needs to be worked around. PS — the problem doesn't necessarily just need to be about Bold or Italic formatting, it could be anything like kerning, tracking, offsets, etc.)

Motion has exhibited several somewhat bizarre aberrations rendering to "share" in the last couple of releases — things that play perfectly in the canvas at any resolution/quality, etc... sometimes don't work in the render. In those instances, I've had to reinvent the entire way I approached the effect.

At any rate, when formatting text, it's best to lay in the entire text first (check your spelling!). Then carefully select and format the portions within that text. It should render out okay after that. (No promises.) If all else fails - use Proxima Nova, or a font you know is not duplicated anywhere else within the System (which Helvetica Neue is—it exists in the /Library/Fonts as well as /System/Library/Fonts folder.. If you've upgraded to El Capitan, you may have noticed that the new San Francisco System fonts are NOT available at the Application level unless you specifically install them yourself.)

Don't take any of what I've said as gospel — like I said: it's just a guess. I've had similar problems show up when just editing text sometimes, and getting certain actions to take effect... sometimes it's like Motion just does not want to cooperate (like when alignments get "stuck" working on only one line of a multi-line entry, [there's a little more to that situation but that's enough said]. ... there are a lot of little problems with the TextEdit tool inside Motion... mostly just minor ones—and there's no excuse what happens during the export render.)

@fox_m

Interesting concept 'bout 'marker artifacts'! Explains the following

same in FCPX, when using two 'styles' in one title-text

This is the standard 'custom' tite .... lower-third is a graphic/animation, not related to that issue)

forename green, family name grey

double-clicking the family name (notice: Inspector tells no format??)

typing a new name = style/format jumps back to factory-set white (on a white background - imagine my reaction 😁)

after 'manual' adjusting color, all fine..

but, somehow, the templates factory set 'white' is kept btw the words, and double-click not just selects the word but its 'format artifacts' before and after ... NOT the blank space itself! ...

.... room for improvement, Apple ........................ 😐

It seems the TextEdit tool in FCPX/Motion is based on a very old model (like MacWrite 1.0, 1984). It's an extremely simple, stripped down interface which may have been compromised when 3D text complicated things a little. The "nodes", back in the olden days used to be called "style runs" in the old "Inside Macintosh." Things get really complicated when you have several overlapping style runs... as in this example phrase... then imagine runs of color and character sizes through the text with differing start/stop locations from the normal/bold/bold italic/italic/normal ranges. 😉

It occurs to me that another method of "easy reset" would be to select all the text, then select a base style from the Style Presets. It helps to have a couple of Style variations based on your "go to" text styles pre-made.

Here's another tip I learned recently:

If you're going to create a complex layout with mixed styles, edit all the text in TextEdit as Rich Text (it's way more stable and hundreds of times easier to use!) Be mindful of the width of the text area so that Tab Stops (if any) will continue to work with soft line-breaks in FCPX correctly. Select the fonts you'll use (and weights) and lay out the complete text for the Title/text entry (do spell-checking too). When finished, simply copy and paste it into the FCPX Title (or other text) [PS: the Layout Method should be Paragraph]. The formatting should be completely retained from one to the other, fonts and all.

Apple has given us tons of very useful stuff to use for a more or less generalized purpose. We all have a tendency to push hard on it from time to time to make the software do things it wasn't originally designed to do. Most of the time it comes through like a champ... others can be a little buggy or simply flat out not work. That's when it gets frustrating 😝

fox_m wrote:

… The "nodes", back in the olden days used to be called "style runs" in the old "Inside Macintosh." …

wow, from the Pleistocene of MacOS .... 😝

Thanks again fox_m for sharing your incredible insights ....!!!

Seems to me an obvious … flaw in the UI, and I'm surprised it was never fixed in the past years ....

<switching to feedback.apple.com> 😀

I wish I'd found this thread before I posted my question...and answer.

My solution was similar to Fox's. Thanks for the in depth explaination.

The problem reminds me of days gone by in desktop publishing when you would get unexpected font results. The reason, I was told, was that sometimes spaces between words, carriage returns (when was the last time you head that term?) or punctuation would have the undesired type characteristics and editing would transmit those characteristics to other type.