0

Long-Standing Text Box Bug (Spaces)

Hi,

Looooooooong-time SF user (Craig S., you may remember me from the old forum).

I just upgraded to SF7 from SF5 and I see that a long-standing bug remains extant. Note that this was not the behavior I remember from SF4 and earlier.

PROBLEMS:  

1) Text boxes populated only with spaces don't expand horizontally, and, the box itself can't be moved to a new position.

2) Text boxes populated with "extra" spaces after the last character don't expand to the right along with these spaces.

PROCEDURE TO REPRODUCE:  

a) Create a text box and type in several spaces (only spaces). The box will not expand to the right. Then try and move the position of that box; you'll find that it can't be moved at all. Next...

b) Edit the text by adding any character after the previously typed spaces. Now the box expands to its expected size, and it can be moved.

c) Edit the text again by adding additional spaces after the last character in the box. The box will not expand to the right.

 

WORKAROUNDS

There are various pseudo-workarounds, but none of them are acceptable for high volume work.

 

Can this behavior be fixed?

 

Best Regards,

Peter Schwartz

13replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • To clarify.... that "boxes can't be moved" refers to dragging a box using the cursor. Boxes can in fact be moved incrementally using the arrow keys, but that's only useful for fine-tuning.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 5 yrs ago
    • Reported - view

    Peter Schwartz I can confirm it's still an issue. It's possible that bug fix priority is influenced by the significance of the issue.

    Can you describe a scenario or workflow where one would being by entering blank spaces and then moving the text box?

    For example, typically one would enter text or spaces followed by text so that the spaces are evident and the text box can be moved.

    If one wanted space on the left and right of the text one would typically select Alignment and center and then one could grab the left and right edges of the text box to expand.

    Please describe a scenario where it would be important to do it by adding spaces, moving the box, adding text, adding spaces to define the right side of the box. Describing the importance of that might impact the priority if the issue.

    Below is typically how I would ensure text with spacing on the left and right.

    Like
  • Hi Craig,

    Great to be in touch with you again, and thanks for confirming this bug. As far as providing workflow examples, well... let me start by saying that for me, this problem is severe that I'm seriously considering using SF 3 to produce my next tutorial series. (As you may remember from our previous discussions, I do video tutorials for MacProVideo, and my SF productions are extremely complex).

    This behavior seems to be in accordance with a rule in software that treats spaces as some kind of "exception" and changes the behavior of text boxes as compared with alphanumeric text. If I'm right about that, making a distinction between a space and any other character makes zero sense to me.

    As you illustrated, space can be added before or after text by stretching the width of a text box with center-justified text. But that's a very specific workflow forced upon the user as a result of the program not acknowledging spaces as being equivalent to any other character. And to have to stretch a text box to create space before and after text is quite time-consuming as compared to simply typing in spaces before and after. But that's not the half of it...

    I routinely use text boxes to create color bars, to mask images or elements of images, and for creating "master" fade-ins and fade-outs over complex, multi-layered elements and animations of various SF objects.

    I also routinely fade out each episode of my tutorial videos. To ensure this renders elegantly in the final export, I add a one or two-frame long blank text box after the end of the last video clip (which crossfades to black). This is absolutely necessary to overcome (yet another) long-standing bug where the last frame of the fade won't render in the export. Placing a blank, black text box at the end solves that problem, because it forces SF to render past the trailing edge of the last frame.

    In short, the usefulness of text boxes extends far beyond merely entering text. But this long-standing behavior with spaces reduces their usefulness to the point of completely hobbling my workflow.

    If I had the time I'd gladly post video examples of all these things. If you really think that producing video examples would help expedite getting this bug fixed, please let me know and I'll see what I can do. Meanwhile, I hope my descriptions above help to make the point.

     

    Best Regards,

    Peter

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 5 yrs ago
    • Reported - view
    Peter Schwartz said:
    I routinely use text boxes to create color bars, to mask images or elements of images,

     Wouldn't you use Annotation for that?
     

    Like
  • CraigS 
    Re using annotations for creating color bars, masking images, etc... No, they're not really applicable for most of my non-text use of text boxes. By comparison, editing annotations is extremely slow and persnickety. Most importantly, perhaps, is that they can't be expanded to nearly a large enough size for covering the entire screen when I do my "master" fade-ins and fade-outs of a scene. This is something I do absolutely routinely. Now, sure, I could use a thick, short annotation line and scale it up to 900% or so to get it to cover the entire screen, and then automate a change in opacity to create a fade-in or -out, but it's far easier/quicker to do this with a text box.

    Annotations are great for what they do (I use them extensively) but they just don't hold a candle to text boxes with respect to the kinds of creative (and utilitarian) things you can use them for.

    And to be completely honest with you, I'm not about to change my workflow to accommodate a bug. It would be far easier for me to work in SF3 to have the text box behavior I've relied upon on for many years, and use SF7 for final-version, pre-export tweaks.


    Regarding dip to black on export.. It's been an issue with SF5 and I believe SF6. I haven't tried it with SF7 yet. If it's fixed then of course that's fantastic! But when it comes to long-standing software issues, I'm of the "once bitten, twice shy" camp and continue to implement workarounds so as not to be disappointed. That said, the other situations I've described for using text boxes are much more significant.

    Best,

    Peter

    Like
  • Ah... Well, this is problematic... Looks like the only earlier version of SF that will open with my current OS is SF 5.0.1 (I don't seem to have an SF3, though I have SF2, 4, and 5).

    And SF 6.2 is no longer accessible, which is really peeving me because when I downloaded the SF7 update (demo), an alert appeared saying that the a copy of SF6 would be made. I took this message at its word. But when I try to open SF 6.2, SF7 opens instead (in demo mode).

    Meanwhile, creating text boxes and populating them with spaces in SF 5.0.1 is a joyous thing indeed.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 5 yrs ago
    • Reported - view

    Peter Schwartz if you have a case number for the text box behavior you should follow up by email explaining your need as you have done here.

     

    ScreenFlow 6.2.2 is still available from our site (we always keep the previous version available). See Previous Versions. 5.0.7 is also available.

    All reports must be about ScreenFlow 7 (you having tested in 7) because all development resources are now being devoted to it. 7 Requires El Capitan and up. 

    Like
  • Peter Schwartz  If I'm understanding what you're trying to do, it sounds like you may be able to use a PNG file of a solid black frame, add it to the new Global Library so its available in all projects, drop it where you need it.  Then crop it, crossfade to/from, etc. that as needed.  Still not ideal but may accomplish what you need quicker than messing with text boxes.  This is essentially what I do for my videos to ensure last frames go to full black.

    Like 2
  • CraigS , thanks the info about the availability of previous versions. Still, gotta say, when the software says it's going to make a backup copy and doesn't, that's fodder for instantly raising someone's blood pressure to seriously dangerous levels. Was that feature not beta tested? GAH!

    Chris Mattia , that's a great idea, thanks.

    Meanwhile, I'll fill out bug reports about the text box bug as well as the non-making of the backup copy of the previous version.

    Like
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 5 yrs ago
    • Reported - view

    Peter Schwartz Thanks for catching those. Perhaps the lack of backup is specific to certain configurations.

    Like
    • Scott
    • International Affiliate Marketer & CBD educator
    • Scott
    • 5 yrs ago
    • Reported - view

    Chris Mattia GREAT tip. I have a similar need for this, and this will work perfectly. 

    Like 1
    • CraigSModerator
    • Telestream Desktop Forum Moderator
    • CraigS
    • 5 yrs ago
    • Reported - view

    Scott Please do report the current text box behavior as a but as well if you think it doesn't work as it should.

    ScreenFlow Support Form

    Like
Like Follow
  • 5 yrs agoLast active
  • 13Replies
  • 347Views
  • 4 Following