Japanese localisation output size increases considerably than the other languages output

Hi Matthew, 

Thanks for the instant reply. 

At client end, even 120 mb SCORM size takes time to load.

Japanese SCORM is taking some more time load than the other languages. Hence, they have asked, that why only Japanese has more SCORM size.

Also, they have asked us to find, if there's any way to reduce the SCORM output size. We have already used the minimum possible quality while publishing the course. So that cannot be reduced more. 

Is there any other way you know?

Regards,

Sayali S.

Yes, we have used the handbrake tool to compress the videos from the course. 

We will try your this suggestion - to run the images through tinypng and tinyjpg before adding them back to the published output. 

I'll get back to you in sometime for the final file size.

Once again, Thanks much! 

Hi Matthew,

Sorry for the late reply. The Japanese package size has been reduced to 116 mb from 145 mb. It wasn't 135, it was 145 mb initially. We have compressed the videos furthermore after publishing the output.

Thanks much for your help!

Hi All,

I have run into an issue with a large SCORM from a Rise course with 9 Storyline blocks. (couple of slides each)

English version was 175 MB, the Japanese version is coming out 465MB

When I looked into which files were the largest the CSS files for each Storyline file are the largest.
Overall the CSS is making up 395MB. This is within "output.min.css" files in each Storyline Ouput.

Is this to do with the Japanese fonts being used? are there solutions to reduce this?

Looking forward to any suggestions to help resolve this, the load lag is heavy.

"output.min.css" is 50-90% font information

but 395 MByte css is strange - normal is 200-1000 KByte (depending on the number of different letters used and different styles - bold, italic, ... )

upload please one of these big css files here in the forum (as zip or 7z)

Hi Jürgen,

Thanks for replying and the information on the font information.
The combination of 5 different files adds up to 395MB. The files range in size from 20MB up to 85MB. I am assuming the larger ones contain more of the characters due to the Storyline file having more text in it.

I had a look inside the CSS files
I see the item below having allot of content that seems to be hashed rendered as letters,symbols and numbers.

@font-face {
font-family: 'MS PGothicBold CharBoldED33A9AC';
src: url(

something is very stange with your file sizes, a normal "complete" japanese font with all characters (about 20000) is  5-9 MByte - as ttf not compressed.

As woff font should be about 3 MByte - all charcters (19688 Glyphs in MS-PGothic)

the woff font is saved in the css as "base64"-text, so the file size increases by 33%

=> the css should be max. 5 MByte per used font

could you zip this 85MB css und upload it here as attachment

Yes agreed.

I did some testing, when I replaced the font with a different one, in the Storyline files the file size for the CSS came down a bit but still larger than 5MB, approximately 30MB. I have gone with this for now as we needed to launch the course.

The font that was causing the larger file size was "Noto Sans CJK JP Regular" and other variants eg bold ,black.

Attached is one of the larger Zips. Password protected. I will PM you the password.

It would be great to understand what the issue is and what a potential solution would be to avoid large file sizes in Storyline SCROMs.

Thanks

this file is large

I have extracted the css to woff files and here is the result
(this was a good test for my extract script)

you have to add 33% to the file size, because the woffs are integrated in the css as base64

unusual is that the 4 large font are almost the same size - very, very strange

let's see if I can find out something else

the result of the check of one of the big font is

https://fontdrop.info/

65535 (2^16-1) glyphen - that's not possible, the woff generator in storyline is broken

open a support case - articulare has to fix this problem

https://articulate.com/support/contact/360-teams

send them a link to this forum post

Vielen Dank Jürgen!

Interesting to hear you have an extract script and see the output and your analysis, very nice!.

I suspected it was something Storyline was doing.

I will log a case and point them to this forum.
Thanks again.

I am having this same problem but my published file set is coming out at 269mb in Japanese compared to the English which is 4mb. My client is not happy as this effects Japanese, Korean and Chinese (Simplified and Traditional)

the storyline otf to woff converter has a strange bug

example
 - NotoSansJP-Regular.otf (4.442 MB) - full char set (windows 11)
 - NotoSansJP-Regular.woff (3.37 MB) - full char set (found on github)
 - NotoSansJP.woff created by storyline 14 MB converted to base64 ( x 1.33) = 18.6 MByte !!!!

Hello! We are facing the same problem with Noto sans cjk font.

May I ask if there a font recommended for Japanese? it cause so much time to load and we think we should change the font in the file...

Many thanks.

Hi Yu Ying Lin,

Thanks for reaching out and I'm sorry to hear you've hit this snag!

I've seen that using MS Gothic font can make the file size smaller. If you're comfortable sharing your file, I'd be happy to do some further testing on my end! You can upload it here or share it privately in a support case. We'll delete it as soon as troubleshooting is complete.