Property and Object labels have a wrong encoding of international characters.
fct 1.13.56 in 7d38d12
See the second object of the last property (should be Březiněves, as it is when I click on it - the second screenshot)
However, on the last page of http://ruian.linked.opendata.cz/resource/katastralni-uzemi/614131 (http://ruian.linked.opendata.cz/describe/?url=http%3A%2F%2Fruian.linked.opendata.cz%2Fresource%2Fkatastralni-uzemi%2F614131&p=1&lp=15&op=-1&last=&gp=1) the same characters are OK, which seems a bit strange:
Is this still an issue as I do not see the utf-8 encoding issues on your screenshots when I access the live pages on my browser ?
/Users/hwilliams/Dropbox/Screenshots/Screenshot 2014-03-09 13.29.35.png
I still have this issue when I access http://ruian.linked.opendata.cz/resource/obce/554782
in fct 1.13.57
This is still happening in 8173801 in fct 1.13.59 http://ruian.linked.opendata.cz/resource/obce/554782
Has anything changed in the Virtuoso Server instance as the page http://ruian.linked.opendata.cz/resource/obce/554782 , does not load with the corrupt characters as in your screenshot above:
No, but the texts are in Czech. So when I view it from here, they load because of my location I guess and they don't load for you. I think that adding &lang=cs to the url should do the trick.
@HughWilliams This is still happening, database here, dont forget the &lang=cs as you will not be autodetected to be in cs environment.
Plus, now it looks like this: (notice the font):
which is probably the same bug as was fixed in a614876 however that was in sparql endpoint, in fct it is still there. However, only in some Chrome instances, which is weird.
@jakubklimek: What is the URL to load as assume it http://localhost:8890/resource/obce/554782 having setup the test database on http://localhost:8890 , but I get a 404 error:
Error HTTP/1.1 404 File not found
The requested URL was not found URI = '/resource/obce/554782'
@HughWilliams That is rewritten by Apache to form correct and resolvable Linked Data URIs. For your instance it will be http://localhost:8890/describe/?url=http://ruian.linked.opendata.cz/resource/obce/554782&lang=cs
Loading the page http://localhost:8890/describe/?url=http://ruian.linked.opendata.cz/resource/obce/554782&lang=cs , I do not see the UTF-8 encoding issue you report, see screen shot attached:
@jakubklimek: This looks like a browser rendering problem as if I view the source of the page I see:
title="Typ MOMC, na něž je statutární město rozčleněno">Typ MOMC, na něž...�sto rozčleněno
So the weird character is generated by browser?
Anyway, I have narrowed it down to an issue in combination with apache mod_proxy_html... I am using that to do the URI resolvablility. When I display the page directly via /describe/?url=... It looks like on your screenshot. However, when I use the resolvable uri via Apache, it is transcoded for no apparent reason - the output document is still utf-8 encoded, but all the special czech characters are destroyed. I am playing with Apache mod_proxy_html now but could not find a solution yet
OK, I found the solution and tested it with a copy of the html page generated by fct. The issue is described here: http://serverfault.com/questions/559518/mod-proxy-html-garbles-non-ascii-characters
Could you add the missing <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> tag to fct generated XHTML output? When this is added there, mod_proxy_html detects the encoding correctly and does not destroy the characters.
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">