Rendering Fonts Properly in MS6

I'm heading out to Joplin in a few minutes. I'll try to catch you tomorrow (Wednesday).

Rich

I'm wondering if this was ever solved for Rich, because I'm having the same issue. Granted, it's on a backup computer with an older video card (we're using it for a couple weeks while parts are still coming in for our regular one we had to rebuild). I just updated to 6.2 b69 from b66, and still getting this exact same issue.

Any insight on solving this would be great. I'll report back also once we get the regular one back up and running - should be done by the end of this next week.

Hi John, and thanks for the update.

I'm not sure I understand the response, though. We can't have both of what? If that past issue you're talking about is fixed, I'm not sure what you're referring to when you say "both". Is a workaround to stay away from light backgrounds?

I didn't notice this with our primary computer, so I'm hoping it's just a temporary issue for us. Our new build should be ready by the end of the week, so I will get back to this thread with an update once that's up and running.

Thanks for the clarification. Our issue (and it looks like Rich's issue, from the pictures above) is the opposite of what you describe - it looks fine (good, actually!) in the preview/edit window. It's on the main display that it looks much worse. It would be annoying, but livable, if the control screen looked worse and the main display was fine. But with the main display looking bad, if this persists in our new build, it might be a dealbreaker. (We've been holding on to v4.5 until this issue with our primary computer came up. We were just doing testing with v6, and are planning to start moving to 6 now with the new build. But we'll have to keep a close eye on this as we test it out.)

Hi John,

When I look at the first two pictures of Rich's it seems like the text is fine when the cursor is in the editing box (i.e. when the box appears around the block of text). So in pic 1, he's editing the metadata at the bottom of the screen, and the lyric text looks bad. In pic 2, he's editing the lyrics, and it looks good. But I would presume when he's done editing and clicks outside of the text box, the text reverts to that "choppy" kind of look.

In pics 3 and 4 the effect is much less obvious - maybe that's because of the Arial font (it looks like Arial, anyway)?

That's what's happening for me. When the cursor is in a text box and I'm making edits - whether to lyrics, or metadata - or whatever (I believe it's happening across cue types, but I'll verify that), it looks like it should. But once done editing, in both the control display and on the main display, the text looks like it's got really bad anti-aliasing, just like in pic 1 of Rich's, above.

If I have time tomorrow I'll upload some screenshots.

Re: resolution, our control monitor use 1280x1024, which is the native resolution of the control LCD monitor. Our main display is 1024x768, which is the native resolution of our projector. We're not using stage display on our backup, since the video card can't handle it and we can't put our newer video card into that computer. But in our new build we'll go back to using stage display on an HD TV. We've run that at both 1280x820 and 1920x1080 (which is the TV's native resolution).

The thought just struck me now that I see Rich's aspect ratio is 4:3, as is ours on the main display. I've had other issues in v6 testing with the 4:3 ratio, which I've conversed a bit about with support. Could it be related to that somehow? I'm wondering if support for 4:3 is lacking since most are likely running 16:9 main displays now?

Again, once I get our new build done, maybe I'll test it using our TV as the main display, just to see what happens.

Thanks again for your prompt responses.

OK, so we've been testing this, and I can confirm that using a white/light background with dark text is all but unusable. When the cursor is in the edit box, the text looks great, as it's supposed to. When I'm done editing and click outside the box, the unwanted outline is added and makes the text looks terrible.

This is really frustrating. I'm building a design for a conference and all of their provided materials are based on a white background. I'm going to have to design something that somewhat fits in with their identity and uses a dark background.

Will there be an update that moves to a new font engine that allows us to display text properly? If one isn't forthcoming, we may be moving away from MediaShout. I'm sad to say that, because I've been using it for 18 years. But with this issue which is such a major one, and with many other little quirks that are making it harder to build our slide decks, I'm not sure it's the best choice to stick with it.

Hi John,

I appreciate the response and the further testing. I’ve found the quality is quite dependent on the font choice as well. A thinner or thicker letterform will look much worse than a medium one.

You’re right that this limitation is quite trusting since it limits us so much in what we can design and display.

Re: v7, is there a timeline on that? And is there a place where we can provide feedback on what we believe should be considered? There are a number of things I’d want to share in terms of user experience - either what seem to be bugs or design choices in v6.

Thanks again. I appreciate the responsiveness.

Quite frustrating, not trusting. :)

Guys, I appreciate this discussion very much. I have utilized some of the suggestions that John proposed in a phone call (which, at this point, I don't remember - sorry) and it improved the quality enough to be usable, though not yet perfect. I can deal with it until the solution is resolved through a rebuild of the text engine.

Thanks, Aaron, for your response as well. I'll be in touch. I completely get that you can't - and shouldn't - incorporate every feature request. Most of my thoughts actually aren't feature requests so much as what seem to be bugs or seemingly odd UX choices.

For the benefit of those who might be watching this thread, this isn't just about the display of the text on the main screen, although that is probably the primary issue. It can also affect the line breaks between when I'm in the edit box and then clicking out of it; a long line of text that goes right up to the edge of the text box can then be pushed to the next line when the outline is applied after clicking outside of the box. It also seems to be cutting off the text of tokens - like a title - that might be aligned to the edge of a text box. (We've tried to add spaces as a workaround - for instance, to a right-aligned title token on the first slide of a lyric - and nothing's worked to prevent the cutting off of the right-half of the last letter of the title. But this doesn't happen on every title. Again, we can work around it with something like a centered title, but that severely limits the design work that we can do.)

The edit box is also exhibiting other very odd behaviour, such as vertically-entered text jumping up to be top-aligned while in the cursor is in the edit box, then being centered again properly once clicking outside of the box. And, if I'm editing text, and I hit the delete key, often the cursor will jump back to the beginning of the text box. But not every time.

I suspect these things are all related to the font rendering engine. And by themselves, they're all quite little things. But these - and a number of other things - are adding up to be quite a lot of frustration for me, and most especially when training volunteers. Personally I can deal with "quirks" because I've worked with it so long and so often. Volunteers have a much harder time dealing with odd behaviour, and rightly so. And every time I need to spend time explaining the "quirks" it does make me wonder if I'm spending my time effectively.

Thanks for your responsiveness. At this point I'll continue to look for workarounds and hope that there can be some fixes forthcoming in other v6 point releases.