105 Replies
Matthew Bibby

I prefer to have conversations about things like this in public, rather than in private support cases (#03038634). It is frustrating when I'm searching the forum for a solution and I find someone experiencing the same challenges only to discover that the potential resolution is only shared in a support case, not also shared in the relevant thread. 

Regarding my comments about SVGs above, a support case was submitted on my behalf and I received the following responses to the point's I've raised.

Point 1: "The latest build I did had a number of SVGs that showed up as solid blocks of colour when published as SL couldn't handle the simple gradients used..."

Support responded with: 

1. SVGs showed up as solid blocks of colour when published

> I tried publishing a sample course with SVG images using the latest version of Storyline 360 but the colors are working fine. You can view the published output here:

https://s3.amazonaws.com/tempshare-stage.storyline.articulate.com/sto_1fnhg3p2ru14ip711f25es1ivg9/story.html

Note that this isn't an issue that applies to every SVG, but rather something that happens to some of them. As I noted originally, this happened to "a number of SVGs" that I was using and seemed to be related to the gradients used.

To be fair, there are actually a couple of issues here, but as I was just quickly noting some issues I've noticed (rather than submitting a support case), I didn't go into detail.

With images that used gradients, the parts of the objects containing the gradients didn't display at all. After I removed the gradients, the SVGs worked fine.

I had some other images where the image was masked (to give it a nice triangle shape) but when published it would appear as a solid block of colour. 

So to be clear, these problems don't happen with all SVGs, just with some of them. And I'd like to know if there are certain features (such as gradients) that the SL SVG implementation doesn't support.

What I find most challenging about this is that these bugs aren't obvious when building the slide. So I add an SVG, build the interaction, test, only to realise the SVG is problematic.

Point 2. "I've also heard reports from a colleague who is having issues with transparency in SVGs." 

> Would you happen to have a sample project from your colleague so I could further investigate this behavior? If you have a copy of his/her files, please upload it here:

https://www.articulate.com/support/upload/case?ref:_00D30Txo._5004y1n7I77:ref 

Since writing my original comment, I've experienced this same issue. Most images with transparency work okay, whereas some don't. When they don't work, the transparent area shows up as a solid block of colour. 

This issue has been reported and discussed in other threads here. So I'm not alone in experiencing this.

Point 3. "States are definitely problematic. If I use an SVG as a button, for example, and add text into the SVG's state, the text simply won't display when published. However, if we start with a shape created in Storyline, then add the SVG and text to that, it works fine."

Support responded with:

> I first imported a couple of SVGs before adding a Hover state to them but the texts on the Hover state are displaying fine. You can test my published course here:

https://s3.amazonaws.com/tempshare-stage.storyline.articulate.com/sto_1fni8ujmi17ja1cu78lm17bf1s0u9/story.html 

Two things to note with the published sample. 

  1. The text is off to the side of the SVG, not sitting on top of it.
  2. Published courses aren't helpful here as there are many ways an interaction like this could be built. As a rule, it might be good to provide the .story files used as well as the published output.

This GIF shows the issue:

This was an SVG I grabbed from a random free site. I then edited the state and pasted a text box in there. On preview, the text box isn't visible. The .story file is attached if you want to test this at your end.

Point 4. "I also had an issue where I used the replace image feature on an SVG. It moved the image to the top left of the screen and deleted all associated triggers/alt text."

Support responded with:

> I also tried reproducing this on Storyline 360 Updates 57, 58, and 59 but the SVG's Alt text and Triggers were retained even after I replaced it with another SVG.

Fair enough. This was a one-off issue and I haven't been able to reproduce it. I'll report back it if happens again.

Point 5. "Oh... and that lovely little hand that appears when the mouse cursor moves over an interactive object? That doesn't work on SVGs."

Support responded with:

> This is working for me as well, both during preview and when the course is published.

No demo was provided here. But I tested this using the attached .story and noted that it was working as expected when hovered on the solid parts of the SVG.

So perhaps the issue I noticed was related to this, but I suspect not as I expect that behaviour with SVGs (and have to actively work to avoid it). I'll add more info when I next come across this issue. 

But you'll note that in this sample shared above, that the hand isn't appearing on hover. It's likely due to no triggers being added to those objects, but I can't check that without the .story file. 

But this GIF shows the problem with using SVGs as buttons. I'd be very surprised if this is the behaviour that people are looking for!

 

Point 6. "And basic stuff like position info not being shown in the ribbon, forcing one to open the size and position window to see that."

Support responded with:

> We don't currently offer this feature, so I submitted a feature request to our product team on your behalf. You may have already received a confirmation email for it.

Why is this considered a "feature"?

When using other image types, that info is consistently shown in the size and position section of the format ribbon. Removing it for SVGs makes your software harder to use and creates an inconsistent and frustrating experience for your users.

In absence of an explanation as to why this isn't currently available, I have to assume that SVG support has been rushed into production without the level of attention such an important feature deserves. I think it is unreasonable to expect your users to submit feature requests to ensure basic functionality in Storyline remains consistent. 

Point 7. "And don't even think about cropping an SVG... that's not an option either."

Support responded with:

> At this time, you can only arrange, group, rotate, align, size, and position SVGs. If you want to crop them, then you can use the media library to open it in a third-party editor, and then save your changes directly to Storyline 360. Here's how:

https://community.articulate.com/articles/storyline-360-managing-a-project-s-assets-with-the-media-library#edit 

I also added this capability to the feature request that I've submitted.

Thanks, I know that I can use a third-party editor, but I don't understand why this is needed. We can crop other images without having to use an external editor and it would be great if the same was possible with SVGs. 

Thanks for taking the time to respond to my concerns. I appreciate it.

Diarmaid Collins

Here's a link to a similar thread from 3 years ago. During the discussion, it was suggested by Articulate that the issues stemmed from us users not adhering to 'best practice', which is, quite frankly, bizarre.

I mean, 2 years AFTER the initial posting, Articulate jump in with the amazing announcement: "Fixed: Arrows and dashed lines were blurry when previewed or published."

Let that sink in.

We, the users of Storyline, have been creating workarounds and hacks to get something as simple as an arrow or dashed line to view pin-sharp, and kind of forced it into our workflow. Unless the client didn't mind (or notice) the blurriness.

It took untold years and innumerable complaints to get something as simple as non-blurry arrows to be presented to us like it was some kind of damned achievement level unlocked.

This is all really basic stuff. I mean, REALLY REALLY basic stuff - MS Painter level stuff. How can you trumpet 360 panoramic interactivity when one cannot make a simple mask within Storyline?

Why herald a 'feature', such as Importing SVGs as an image file, when its functionality is different to any other image instance, with regards Points 6 and 7 mentioned by Matt above?

After importing even a simple, single colour icon, one cannot alter the transparency of the SVG, to use, as, say, a watermark, in a course. It's nonsense. One cannot even use the old PNG trick of importing the icon as a white line SVG and select Format > Recolour. 

The previously trumpeted 'feature' of being able to Import SVGs From Powerpoint, which allowed SO MUCH AWESOME flexibility, despite being a technical process, was actually a much better solution than what is now offered, and even that methodology has now been broken. Instead of importing as shapes, the SVG is now an awkward uneditable, un-tweakable, fully-opaque image.

The ability to do basic stuff WITHIN a software programme is kind of the point of most software programmes I use. Not many ask the user to use another, possibly more highly specialised third-party product to do basic stuff like creating bespoke shapes (c'mon, why can't we combine, break apart, tweak any shape combo within Storyline itself?), Masks (seriously, it's almost 2022 now!), import and/or store bespoke gradients, the ability to specify corner roundness/bezel values of ANY corner, (and not have to rely on flipping, inverting and rotating a shape to get the desired result thereby rendering all the internal geometry of the shape out of whack)...

There are so many basic features being asked for, including getting features that are actually in Storyline to work (Hello Format Picture > Picture > Blend > Mode... I mean, seriously WT-ACTUAL-F is it there for? It does not work, never has and shows such sloppy attention to detail, UX and interface design, and what Articulate really think of its user base).

Launching SVG Direct Import as a major achievement and to have the reality of it be so utterly disappointing and fundamentally broken clearly illustrates that Articulate is simply relying on loyalty (and fear of the unknown) to maintain revenues without addressing some nearly decade-old issues that are so blatantly, inanely, absurdly rudimentary to functionality is beyond depressing. It's despairing. It shows such a lack of vision, such a lack of understanding of who uses this software and what it is there for, and such a lack of respect to these same users who for years have been pleading to "get things fixed first, new features later".

Also, anytime something new is announced, something old gets broken, such as the annoying glitch whereby if one clicks on VIEW > SLIDE MASTER and then VIEW > FEEDBACK MASTER the screen jumps to the SLIDE VIEW.

Sloppy.

Diarmaid Collins

I just wanted to add this as well - here are the settings I have in Illustrator for my SVG exports. It's the default, AFAIK, but I have had no issues with these settings using the now-defunct Import From PowerPoint method.

I also have to note that I am not having any transparency issues with these settings.

Maybe these can be tweaked for more editability within Storyline but I haven't the time to test it out yet. But for anyone confused with other SVG software setting out there, this might help.

SVG settings - ILLUSTRATOR

Michael Marcos

Hello everyone,

Thank you for these valuable pieces of information. It looks like the focus of the thread got steered towards issues with SVG, but there seem to be a few different (but related) issues across the different posts.

I would like to start with the issue presented by Mark since he got this thread going. The degradation observed here is the scaling between the original image and the published output. EDIT/Rephrased to avoid confusion: "Unlike vector image formats like SVGs, EMFs, or WMFs, raster image formats like PNGs and JPGS will suffer a loss of quality when scaling."

Screenshots in general are best displayed without any scaling. As an example, Here is a basic html page referencing a screenshot of a Wikipedia page taken on a 1920 x 1080 monitor without using Storyline. If the page is viewed in full screen on a monitor with the same resolution, there is little to no degradation. However, once the browser is resized down, the degradation starts to manifest as early as 80%. If we take the same page, and view it on a 1366x768 display, the text becomes barely readable while the images are still ok. Our best practice document suggests to use images that do not need to be scaled to mitigate the loss of quality in the published output. Zoom images can also be used to display images at their original dimensions.

Matthew, thanks for breaking down the SVG problems into different points. For 1 and 2, would you be able to attach the raw SVG file here so that we can take a closer look? If not, you may use the same upload link in the support case to send it to us privately. For point number 3, this is something that we are aware of and are currently working on. I’ll skip number 4 because we cannot reproduce the issue either. Point number 5 is expected behavior for SVGs that have transparent areas. There is nothing being “hit” which is why the state is not being triggered, much like how an illustration with non-filled areas behaves. You could try filling these areas within the SVG with a solid color to get the behavior you desire. Point number 6 is definitely not a feature request and is something we will fix. Thanks for bringing that to our attention! Cropping SVGS (point 7) on the other hand is a feature request that we are not working on currently.

And thank you Diarmaid for sharing that helpful tip along with your feedback about SVGs. I'd like to assure you that these points have made their way to support and have been made aware of the issues highlighted in this thread. 

 

Justin Grenier

Sure thing, Mark.

Here's a screenshot of what Mike's mocked-up HTML page looks like in a 1920 x 1080 browser window, and here's a screenshot of what Mike's mock-up looks like in a 1366 x 768 browser window.

I think our goal was to demonstrate that we'd expect any text-heavy screenshot to suffer from a loss of quality when scaled, inside or outside of Storyline.

Diarmaid Collins

Hi Mark. I took the liberty of peeking into your file and checking things out. I completely understand your frustration because I can find no reason why it displays blurry upon preview or publishing.

One caveat; I notice a lot of folks do this so it's not pointed at you - PNGs are only necessary to use whenever your bitmap image has a transparent section. If it doesn't then a JPEG is the optimum file format. The reason is that PNGs tend to be far larger in 'size' than JPEGS.

Which brings me to JPEG image compression.

Generally, the more compression applied to a JPEG upon export the more degradation there is in the image (blurriness, pixelisation, artefacts, etc). I have uploaded a version of your file to Review with 4 buttons that show whatever differences there are between the formats and compression.

Weirdly, there is little or no difference in the visual result between your original PNG (2048x1536px which scales down to 720x540px in the SL360 file), a straightforward high quality (zero compression) JPEG and a resized JPEG (720x540px import - actual size).

The only noticeable difference is in the third option which was the original size JPEG compressed to Very Low Quality (10) and the result is predictably bad. 

But what is concerning is that this deliberately bad image is not really that far off from the other 3. So yeah, conclusive proof that I have no idea what is happening to your image. there is no reason, AFAICS, for the quality to publish so poorly.

Not sure if this helps at all.

https://360.articulate.com/review/content/e203cc0d-6e22-4864-95f4-d0b4a3866d2b/review

Mark Kirby

Hi Diarmaid,

It does help, because at least I don't feel like I'm expecting something unreasonable. It's crushing to see your work almost vandalized when you publish it. People naturally assume it's incompetence from the author, either in the creation of the material or the selection of the delivery platform.

Matthew Bibby

Mark, thanks for sharing your image. Here's how things look when I publish your course as-is:

Here's a section of that image (sized 100%, just cropped so it displays clearly here):

If I then export your image from SL (using the export original image option), rename that image to match the file name used by Storyline and drop it into the mobile folder of the published output, I get the following:

Close up from that image:

Image quality settings in SL are set to 100%, which should mean that the images aren't compressed at all. But that isn't the case here.

The above, which you can test yourself using the same files, clearly shows that there are issues with the way SL handles images that are not due to the file type or the size that the image is displayed. 

Here are those two images together:

Articulate, can you please let us know if there is a way to add a PNG to Storyline that will not be degraded during the publishing process? 

Diarmaid Collins
Justin Grenier

Sure thing, Mark.

Here's a screenshot of what Mike's mocked-up HTML page looks like in a 1920 x 1080 browser window, and here's a screenshot of what Mike's mock-up looks like in a 1366 x 768 browser window.

I think our goal was to demonstrate that we'd expect any text-heavy screenshot to suffer from a loss of quality when scaled, inside or outside of Storyline.

Hi Justin,

Thanks for showing the impact on text quality and images when scaling downwards.

How does Storyline best practice, which encourages images to be imported to a file at the exact size it should be within the file, accommodate most users who utilise the Modern Player which automatically scales (upwards) to fill the screen display?

Personally, I find that if I import an image that is twice the size of the intended image I have no issues with image quality when viewing my work on high-resolution monitors where the file displays many times the 'specified' Storyline file.

Is it an issue with Storyline internal settings compressing images on, say like Mark's file, at 720x540, and then being scaled upwards within the modern player? 

Matthew Bibby
Diarmaid Collins

Personally, I find that if I import an image that is twice the size of the intended image I have no issues with image quality when viewing my work on high-resolution monitors where the file displays many times the 'specified' Storyline file.

 

I just did a test using a screenshot of Wikipedia. It was captured at 1440x1040, then dropped into a default SL file, which is 720x520.

The top image is SL's native publishing, the bottom is how it looks when I replace the published image with the original.

So even when working with images 200% the desired size, there is still a problem:

 

Comparing the two images shows that some kind of compression is applied during publishing:

Michael Marcos

Thank you everyone for your patience, and apologies for the slight confusion on the file types! Let me take your findings back to the team Matthew so we can review this function of Storyline 360.  I just want to confirm that when you say you "replaced the published image with the original", this means you went into the Storyline output\mobile folder after publishing and replaced the processed image with a raw version of the same image?

EDIT: Nvm, I just saw your earlier post confirming this. Thank you.


I really appreciate the extra effort you've all put into this.

- Michael Marcos
Customer Support Product Liaison 

Diarmaid Collins

Full disclosure - I don't generally import images with text in them so I don't encounter this issue that often. It's clearly obvious that text is affected. I think there is probably more leeway with images without text. I, unfortunately, tend to recreate any charts, diagrams or text images within Storyline itself to bypass these publishing issues (yet another productivity limiting 'hack' or workaround that's been embedded into my workflow).

But, from the link I posted a little bit further up, there is (was) clear degradation in image quality if the image is embedded in a non-rectangular frame. This may be fixed now but if I require bespoke image 'frames' I do it outside Storyline and import the image as a transparent PNG - just another workaround to broken Storyline functionality. I have not tested if it's fixed.

But at least we know arrows are no longer blurry.

Michael Marcos

I'm just circling back here to let everyone know that we will be taking investigating this further on our end. The results Matthew got from the steps he documented earlier are not expected behavior. I can't give an ETA on how soon it will take to fix this as that can change depending on how complex of an issue the original image quality issue may turn out to be though.

Thank you again for your patience as we continue to chase down this issue!

Matthew Bibby

Great news, thanks Michael. I'll get back to you regarding the issues I was having with SVGs, am just waiting to get permission from my client to share the problematic SVGs.

While you are investigating this issue, can you please also look into whether or not it would be possible for Storyline to use TinyPNG and TinyJPG for image compression? If you could you'd get dramatically smaller file sizes with very little quality loss.