I do not, but I would encourage you to continue working with support so that we can understand and identify the issue. Brett is still working with our support team as well.
Hi Leslie, the support team has been WONDERFUL! I followed their instructions, and so far everything is working as it should. Please tell everyone how much I appreciate the support and quick responses.
Tricia, what did you do that got everything working for you as it should?
I just tried again to see if I could narrow things down more and here's what I've discovered. I can change the font of a text box that is using numbering to a Microsoft Office installed font, e.g. Arial, Calibri, Cambria, Comic Sans, Georgia, etc. and I don't have a problem; I can edit the text box as normal and everything works fine. If, however, I change the font to a non-Microsoft Office font, e.g., Myriad, Minion, Adobe Caslon Pro, Garamond, etc., it crashes it every time.
For reference my support case number is #00425031. And I agree, the support folks have always been great. But I'll be happier we this is sorted out.
Hold on Brett, it crashed right after I posted yesterday. I thought it had something to do with Microsoft .NET Framework 4 vs 4.5.1.
Here is what I just learned:
If you corrupt a project by editing text that is NOT Microsoft Office installed font, and then use FIle > New to create a new project, that project is corrupted as well.
However, if you close SL2, re-open it and create a new project, you can enter any font type you want. You can freely edit fonts that are Microsoft Office installed. If you try to edit non MO fonts, SL2 is corrupted.
Brett, I've done more testing, and it seems as if you are correct about the font type. I crash whenever I attempt to edit a numbered list that is Open Sourced font.
Crash only happens with the following conditions:
Non-Microsoft Office installed fonts AND
Numbered lists (bulleted lists are fine) AND
Editing numbered lists AND
List item being edited is non-Microsoft Office installed font (list item in other fonts are fine) AND
Cursor is at the end of the list item line AND
Either on a Slide text box OR in Notes pane
Interesting thing to note: I can edit a numbered list w/out issue using True-Type font OCR A Extended. OCR A Standard (open-sourced font) causes the crash. Same happens with Cooper Black (TT) vs Cooper Black Std (O).
In Notes pane, Brush Script MT (TT) is fine, but Brush Script Std (O) causes the crash.
On slide, Brush Script MT (TT) and Brush Script Std (O)are fine
It looks like the solution (for now) is to use MS installed fonts. Good tip!
I would agree with everything, except I am finding that the error also occur when the cursor is at the beginning of a line. If I place the cursor at the end of a line, I can usually press delete to back up the next line into the current one, at which point I can then edit, and press Enter to return it to it's own line.
This bug is hair-pullingly frustrating, especially since I am trying to update time sensitive information for an Ebola Preparedness course.
Great summary indeed, Tricia. I'm still having this issue and I know Miker is working with the QA team on it but no solution yet.
Here is an interesting tip that might help. If you have a text box with numbers applied that is in an non-MO font and want to edit it, first change it to Arial, make your edits, then change it back to whatever your original font was. That has worked for me on a few occasions but is a pretty clunky workaround. (It's also pretty dangerous because if you slip up and change the text while you're in the non-MO font you'll crash Storyline and destroy your file. Tread with caution!)
I've been copying the text into Notepad, making the changes there, and then pasting it back into SL2. It usually works. However, like you said, tread carefully.
I'm looking forward to the fix for this issue. We SURELY can't be the only people experiencing this.
Hi Sarah,
I'm sure we're not the only ones. In my office alone we have three installations of SL2 with the same issue and it happens to me with my MacBook Pro at home. Frankly, I've yet to see it work... Funny thing is, we never had any problems with numbering in SL1. And the other great improvements to text editing make it almost worth it to avoid using numbering.
I just wanted to update this thread, that the issue is still with our QA team, but it looks like they were able to replicate the behavior and are looking into the fix now. We'll share an update here once there is additional information.
20 Replies
Hi Tricia!
Thanks for mentioning your support case and I know that you are also corresponding with users here.
Hi Leslie! Do you have any ideas for a workaround?
I do not, but I would encourage you to continue working with support so that we can understand and identify the issue. Brett is still working with our support team as well.
Hi Leslie, the support team has been WONDERFUL! I followed their instructions, and so far everything is working as it should. Please tell everyone how much I appreciate the support and quick responses.
Awesome, so glad to hear it Tricia!
Tricia, what did you do that got everything working for you as it should?
I just tried again to see if I could narrow things down more and here's what I've discovered. I can change the font of a text box that is using numbering to a Microsoft Office installed font, e.g. Arial, Calibri, Cambria, Comic Sans, Georgia, etc. and I don't have a problem; I can edit the text box as normal and everything works fine. If, however, I change the font to a non-Microsoft Office font, e.g., Myriad, Minion, Adobe Caslon Pro, Garamond, etc., it crashes it every time.
For reference my support case number is #00425031. And I agree, the support folks have always been great. But I'll be happier we this is sorted out.
Hold on Brett, it crashed right after I posted yesterday. I thought it had something to do with Microsoft .NET Framework 4 vs 4.5.1.
Here is what I just learned:
My cases are: 00427345 and 00427140
Brett, I've done more testing, and it seems as if you are correct about the font type. I crash whenever I attempt to edit a numbered list that is Open Sourced font.
Crash only happens with the following conditions:
Interesting thing to note: I can edit a numbered list w/out issue using True-Type font OCR A Extended. OCR A Standard (open-sourced font) causes the crash. Same happens with Cooper Black (TT) vs Cooper Black Std (O).
In Notes pane, Brush Script MT (TT) is fine, but Brush Script Std (O) causes the crash.
On slide, Brush Script MT (TT) and Brush Script Std (O)are fine
Great summary, Tricia.
It looks like the solution (for now) is to use MS installed fonts. Good tip!
I would agree with everything, except I am finding that the error also occur when the cursor is at the beginning of a line. If I place the cursor at the end of a line, I can usually press delete to back up the next line into the current one, at which point I can then edit, and press Enter to return it to it's own line.
This bug is hair-pullingly frustrating, especially since I am trying to update time sensitive information for an Ebola Preparedness course.
Is there a fix in the works?
Hi Tricia and Sarah,
Great summary indeed, Tricia. I'm still having this issue and I know Miker is working with the QA team on it but no solution yet.
Here is an interesting tip that might help. If you have a text box with numbers applied that is in an non-MO font and want to edit it, first change it to Arial, make your edits, then change it back to whatever your original font was. That has worked for me on a few occasions but is a pretty clunky workaround. (It's also pretty dangerous because if you slip up and change the text while you're in the non-MO font you'll crash Storyline and destroy your file. Tread with caution!)
Thanks for sharing this workaround Brett!
Thanks for the suggestions, Brett.
I've been copying the text into Notepad, making the changes there, and then pasting it back into SL2. It usually works. However, like you said, tread carefully.
I'm looking forward to the fix for this issue. We SURELY can't be the only people experiencing this.
Hi Sarah,
I'm sure we're not the only ones. In my office alone we have three installations of SL2 with the same issue and it happens to me with my MacBook Pro at home. Frankly, I've yet to see it work... Funny thing is, we never had any problems with numbering in SL1. And the other great improvements to text editing make it almost worth it to avoid using numbering.
Hi all,
I just wanted to update this thread, that the issue is still with our QA team, but it looks like they were able to replicate the behavior and are looking into the fix now. We'll share an update here once there is additional information.
Thanks Ashley. I appreciate the update.
Hi! Just wanted to pop in and let you know that Update 2 for SL2 has been released which includes correcting this issue.
Yahoo!
:)
Just tried it... and it WORKED!
Awesome, thanks for the update Brett!
Happy Friday!
This discussion is closed. You can start a new discussion or contact Articulate Support.