(solved) FancyIndex Export's Errors

[mujianxiuxi]

Tested with Bookpedia 4.6.2, Dvd & Gamepedia 4.6.1. When export finished, nothing will open automatically like other export template. And I can not find a proper way to open

The exported folder contains 2 sub-folders called "details" and "Images" respectively. In the "details" folder, opening the file "index.html" , it turned out to be the first item entry with broken link of cover art and rating (I think, see below), and there is no real index file.

At the same time, Safari report 2 errors occurred in opening of the "index.html": both are "The required URL was not found on this server", specifically one is that the cover jpg of the first item was not on the desired place, the other is about the "star0.gif.white.gif". In fact, these files existed, but in the wrong place.

With Bookpedia, I use the fancy index plug-in that come within the 4.6.2, with Dvd&Gamepedia, I use both the plug-in within 4.6.1 and those downloaded and installed. Either way, the consequence is the same.

Any help would be appreciated.

[Conor]

Sounds like the export is not completing. If that is the case Bookpedia would report an error into your console log. Could you please send us any Bookpedia messages in your console log after exporting. To view the console log use the program of the same name in your utilities folder, new messages are at the bottom of the log.

[mujianxiuxi]

Console says:

Code: Select all

10-11-3 A.M. 10:47:06	Bookpedia[216]	Error writing export file Latin1: The file “page1.html” couldn’t be saved using text encoding Western (ISO Latin 1). Text encoding Western (ISO Latin 1) isn’t applicable.

10-11-3 A.M. 10:47:06	Bookpedia[216]	LSOpenFromURLSpec() returned -43 for application Safari.app path /Users/myname/Desktop/exportname/index.html.

My default language is a non-Latino characters one. I tried to switch the default to English and the same reported by console.

No matter whether those exported entries contains only Latino characters or not, the same errors ... But of course I'm not pretending to know what that console was saying about

[marumari]

FancyIndex itself specifies UTF-8 as the character encoding, so I don't know what the issue would be with the template itself. Do the other templates produce a similar error?

[mujianxiuxi]

it seems ... solved, though with undetermined reason export failed again in rare cases.

thanks for Conor and marumari's tip and hint.

the problem was caused by, in my case, Simplified Chinese characters on the Date Format.

Change the Date Format in preference>general of the Pedias to m%, previously it's "b%". And export nicely complete in most cases. (In my case, Simplified Chinese is the default language of the system, so "b%" could cause the Pedias to out put a Chinese character in the month field like “11月”. I didn't noticed this "月" when I wrote last post saying that there were no non-Latino characters, sorry. )

Hope Fancyindex developer may notice and tinker with this localization issue. But I don't know whether other non-Latino character will cause the same issue.

@ marumari:
Other templates play good with me, do not need such an alternation on Date Format like Fancyindex.

[Conor]

Thank you for the console log and the extra information about the Chinese characters. I have updated the templates to be able to handle that. If you would like to use Asian characters in the current version add the following code into FancyIndexDetails.html template file that comes with the program.

Code: Select all

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

Without that line DVDpedia does not know the character set for the file and assumes the lowest default of Latin1.

[mujianxiuxi]

thanks, I believe with next update this problem will be gone.

[marumari]

Good catch, Conor. You don't generally need that for AJAX page loads (since it takes the charset of the calling page), but I guess I hadn't thought about the Pedia exports reading that in.

You may want to look through the other templates -- iPhoneGroupedDetails.html, for example, uses iso-8559-1.

[Conor]

iPhoneGroupedDetails.html, for example, uses iso-8559-1

I'll be update all the templates to be UTF-8 as enough time has passed for all web servers to support it. Including the now defunct .Mac that used to have problem with it.