Rendering Fonts Properly in MS6

Nov 21, 2017
Rich Gardner wrote
I have called tech support at least twice about this phenomenon and they do not have an answer for me, even after seeing it with their own eyes from a remote login.
I use Arial 36 for most of my lyric projection. When clicking in the text box (to edit a lyric or whatever) the text renders perfectly fine in the text box, but when finished and clicking to project the text, the quality of the text is horrible! It even appears to be rendering with a different character set! For instance, the copyright symbol renders fine in the text box, but appears kind of like a gun sight with cross hairs on the projection. This doesn't happen on all songs, just on some songs. I am attaching a couple of screen shots so you can see what I'm talking about.
The first shot is with the copyright text box selected. You can see that the text is full bodied in that window, but the lyric text is wimpy.
The second shot is just the opposite. Now the lyric text is full bodied and the copyright info text is wimpy and the copyright symbol is incorrect.

Here's another song with the same two text box selections. As you can see, the text renders correctly in both, as far as I can tell.

Any ideas?

I have been told a couple of times that development has been considering the possibility of redoing the text engine, but at this point it seems unlikely. Is that correct? Is this a problem that could be resolved without needing to redo the text engine? HELP!

Rich Gardner
New
1 vote
Vote
Reply
19 Answers
Nov 21, 2017
John Phillips agent wrote
Rich,

Since this is more of a support request, I would like to remote in and have a look my self. Since it does not happen on all songs, it could be an issue with templates or something that is not detected by the usual troubleshooting.

I just sent you an email with my contact information. So if you have a chance, please give me a call so we can take a look at it together.
Nov 21, 2017
Rich Gardner wrote
I'm heading out to Joplin in a few minutes. I'll try to catch you tomorrow (Wednesday).

Rich
Nov 21, 2017
John Phillips agent wrote
Talk to you then.
Jan 20, 2018
Michael Schutz wrote
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.
Jan 22, 2018
John Phillips agent wrote
Hey guys,

I just had another conversation with the developers to see if there is a possible solution for this in V6. Unfortunately, with the current text Engine, this is not possible. We had an issue in the past that caused a small outline with white text on white or light colored background even when no outline was applied. This issue has been fixed, but because of our current text engine, we can't have both.

My Apologies.
Jan 22, 2018
Michael Schutz wrote
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.
Jan 22, 2018
John Phillips agent wrote
When they fixed the issue with the persistent outline on the white text, it effected how Black text is rendered. It is like the outline was applied to both Black and White text even though the outline was not used. Now with Black text with no outline, it looks a little rougher in the preview /edit window. The developers tried to make black and white text look the same, but were not able to, without reintroducing the persistent outline.
Jan 22, 2018
Michael Schutz wrote
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.)
Jan 22, 2018
John Phillips agent wrote
Michael,

Based on the reports and what I am seeing here, it only seems to effect the Preview/Edit window. What resolution are you setting on the Main display in MediaShout?
Jan 22, 2018
Michael Schutz wrote
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.
Jan 23, 2018
John Phillips agent wrote
Michael,

You are correct. The images provided were to show what happen if the text object is selected. The request here was to improve what is seen in the Editor.

The screen resolution or aspect ratio will have no effect on this. The reason I asked about your screen resolution was because you stated you are seeing this on the projected screen. We have not minimized or reduced the support of 4:3, so 1024x768 should be fine.
Mar 08, 2018
Michael Schutz wrote
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.
Mar 09, 2018
John Phillips agent wrote
Michael,

I totally understand the frustration, and apologize that it's not working to your satisfaction. I don't think we will be able to rebuild the text engine for V6, but I do know that V7 is being rebuilt from the ground up and should not have these types of issues.

I did do some more testing and found that id a dark Brown or Blue is used, the text is considerably improved. Attached are screenshots of this running at 1024x768. Hopefully this will help.
Mar 09, 2018
John Phillips agent wrote
Michael,

I also found that if you go one shade lighter than black and use a Dark Gray, the quality is improved.
Mar 09, 2018
Michael Schutz wrote
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.
Mar 09, 2018
Michael Schutz wrote
Quite frustrating, not trusting. :)
Mar 12, 2018
Aaron West agent wrote
Michael - there is no timeline on V7 yet. At this point, we have just begun discussions on what we are planning, which as John mentioned involves a rewrite of some key components that we have hung on to for too long. If you have suggestions, please feel free to send those to me at Aaron {at} MediaShout {dot} com and I’ll look through them to see what we are planning and what we might be able to improve upon. Of course, as with all versions, we do our best to serve as many people as we can and although we would love to get every request into the program for ever user’s situation, that is not feasible as the program would become unusable and very, VERY clunky. Thanks for understanding.
Mar 13, 2018
Rich Gardner wrote
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.
Mar 13, 2018
Michael Schutz wrote
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.