Problem with diacritics in the SCORM package

[Jakub Wasielewski]

Hi everyone,

I use scorm materials in OpenOLAT prepared in the iSpring software. With their display there are no problems (all Polish letters appear) and they work correctly.

We started to test the scorm packages prepared in Articulate and there was a problem with displaying Polish diactric characters. After uploading to OO, the package starts, but instead of the Polish letters I get "bush" (they do not display correctly and the text is unreadable).

After generating the package and placing it on Articulate LMS, the Polish characters are displayed correctly. It's the same as generating content as html.

I checked the encoding settings and I have UTF-8 set everywhere (the same as for packages prepared in iSpring). The OO coding (application and base) is also set to UTF-8.
I am using OO in version 12.2.8.

Have any of you encountered such a problem? What can it cause?

How can solve it?

greetings

Jakub

[Jakub Wasielewski]

Hi again,

I forgot to write one important information - in both programs we compile SCORM in HTML5 format whitout flash. When i use in Articulate mixed format of SCORM (flash/HTML5) all fonts displays correctly.

Greetings

Jakub

[Florian Gnägi]

Hi Jakub

Did you set the encoding manually to UTF-8 in the single page configuration? Sometime the automatic detection does not work (it depends on some HTML elements within the page). Also, check if the encoding for the JavaScript is set to the correct encoding. We assume that the JavaScript files are encoded using the same enconding as the main HTML page. However, this assumption can be wrong and there is no way to find it out as there is no specification for this. For example, if your JS files contain text strings and those are encoded using ISO-Latin, but your page is in UTF-8 - things will be mixed up. 

Cheers

Florian

--
--
Sie erhalten diese Nachricht, weil Sie Mitglied sind von Google
Groups-Gruppe "OpenOLAT".
Für das Erstellen von Beiträgen in dieser Gruppe senden Sie eine E-Mail
an open...@googlegroups.com
Um sich von dieser Gruppe abzumelden, senden Sie eine E-Mail an
openolat+u...@googlegroups.com
Weitere Optionen finden Sie in dieser Gruppe unter
http://groups.google.com/group/openolat?hl=de
-------------------------------------------------------------------------------------------------------------------
OpenOLAT - infinite learning - http://www.openolat.org

---
You received this message because you are subscribed to the Google Groups "OpenOLAT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openolat+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--------------------------------------------------------------------

professional services for the e-learning system OpenOLAT

hosting - operating - support - development - mobile - consulting

--------------------------------------------------------------------

www.frentix.com | www.openolat.com 

frentix  GmbH

Florian Gnägi, Geschäftsführer

Hardturmstrasse 76

CH-8005 Zürich, Switzerland

tel://+41-43-544-9000

dir://+41-43-544-9001

fax://+41-43-544-9009

Find me on wire skype twitter xing linkedin 

--------------------------------------------------------------------

[Jakub Wasielewski]

Hi Florian,

Thank you for the hints and help. Today we will check what you have given.

Packages we have automatically generated by articulate and we already know that not only is this problem with us, but it has also appeared on moodl. We did not set encoding manually.

If we find a solution, I will try to put the information on the group as well.

greetings

Jakub Wasielewski

[Jakub Wasielewski]

Hello everyone,

As promised - I post information what was wrong.

We have checked the SCORM package in the field of character encoding. Just as Florian wrote earlier - there was a confusion of different encoding of file. For html and JS we had different encoding settings (Windows, Latin and utf).

In addition, end-of-line markers were also mixed up.

After setting the encoding to UTF-8 without BOM and end-of-line markers on the UNIX LF, the problem has disappeared.

greetings

Jakub Wasielewski