|
|
Post by lcurtisboyle on Feb 16, 2008 18:01:05 GMT -5
I have hit one little snag when exporting HTML, including pictures... it appears that long filenames, for some reason, do not work propery in the HTML version. PA Writer will view them properly itself from the Wallet, and shows the "MacOS9ifieid" version of the filename (with the # and digits past the 25th character), and original folder they are in shows the full, long filename version. When I export it to HTML, it names the file in the resulting HTML folder with the shortened version, and looking at the HTML source, it seems to match (using the shortened version), but it will not find it (shows a broken link). I even tried changing the '#' in the filename (in the HTML source) to a '#', but that doesn't seem to help either.
I finally found what will work - using the URL escape code '%23'. Replacing all references to the '#' in the HTML source with '%23' (but only when defining URL locations - like filenames) does let it work properly.
I also tested it from Win XP (running under VMWare Fusion), and it works exactly the same (does not work properly) under Opera 9.21 (didn't on Mac Opera or Safari either), or Internet Explorere 7.0.5730.13. The '%23' trick fixed all of them.
I don't have an OS9 capable machine any more to test on, but would that same sequence work properly there, in which case a small patch to your code to replace an URL identifiers with embedded '#' with '%23' would fix this problem for all browsers?
|
|
|
|
Post by Howard Metcalfe on Feb 16, 2008 21:06:10 GMT -5
I have hit one little snag when exporting HTML, including pictures... it appears that long filenames, for some reason, do not work propery in the HTML version. PA Writer will view them properly itself from the Wallet, and shows the "MacOS9ifieid" version of the filename (with the # and digits past the 25th character), and original folder they are in shows the full, long filename version. When I export it to HTML, it names the file in the resulting HTML folder with the shortened version, and looking at the HTML source, it seems to match (using the shortened version), but it will not find it (shows a broken link). I even tried changing the '#' in the filename (in the HTML source) to a '#', but that doesn't seem to help either. I finally found what will work - using the URL escape code '%23'. Replacing all references to the '#' in the HTML source with '%23' (but only when defining URL locations - like filenames) does let it work properly. I also tested it from Win XP (running under VMWare Fusion), and it works exactly the same (does not work properly) under Opera 9.21 (didn't on Mac Opera or Safari either), or Internet Explorere 7.0.5730.13. The '%23' trick fixed all of them. I don't have an OS9 capable machine any more to test on, but would that same sequence work properly there, in which case a small patch to your code to replace an URL identifiers with embedded '#' with '%23' would fix this problem for all browsers? Hi, Is the problem with just long file names, or with file names containing a # sign? Perhaps you could give me some file name examples. I think I don't quite understand the problem. Best, Howard |
|
|
|
Post by lcurtisboyle on Feb 16, 2008 22:31:49 GMT -5
It is the # sign in particular that seems to be the problem, and it has to be "escaped out" by using the %23 in it's place in any filename references in the HTML source (IMG SRC, A HREF are the two I have changed). The problem occurs whenever one has image files with >31 characters in it; the routines you are using (I am assuming OS9 file calls) use the converted filenames (25 chars, a #, and a unique hex identifier), and most browsers can not handle the # directly in the filename, without escaping it. Two solutions would be 1) use OSX file calls for the full 255 character filenames (but this would likely break you're OS9 compatibility... probably not a good solution), or to change the filenames to use %23 in place of any # signs that show up.
|
|
Dave
New Member
Posts: 19
|
Post by Dave on Feb 17, 2008 6:36:42 GMT -5
I say break the OS9! hehe.
|
|
|
|
Post by Howard Metcalfe on Feb 17, 2008 14:40:37 GMT -5
It is the # sign in particular that seems to be the problem, and it has to be "escaped out" by using the %23 in it's place in any filename references in the HTML source (IMG SRC, A HREF are the two I have changed). The problem occurs whenever one has image files with >31 characters in it; the routines you are using (I am assuming OS9 file calls) use the converted filenames (25 chars, a #, and a unique hex identifier), and most browsers can not handle the # directly in the filename, without escaping it. Two solutions would be 1) use OSX file calls for the full 255 character filenames (but this would likely break you're OS9 compatibility... probably not a good solution), or to change the filenames to use %23 in place of any # signs that show up. My testing only covered alpha names that were relatively short. Sorry. I will look into this some more. Thanks. Meanwhile, don't use file names greater than 31 characters and, as noted in the Reference guide topic Basic Navigation > Accessing Pictures, keep each picture path to less than 248 characters. Howard |
|
|
|
Post by Howard Metcalfe on Feb 17, 2008 14:46:26 GMT -5
I say break the OS9! hehe. Hi Dave, Always good to hear from you. Howard |
|
|
|
Post by lcurtisboyle on Feb 17, 2008 17:34:31 GMT -5
I did see the path size limit, and since my images are all in the scrapbook (and thus not using full pathnames), that wasn't a problem. PA Writer itself handles the filename conversion fine (or I wouldn't be able to view the wallet images either); it is just browsers trying to reference those filenames that are having the problem. I assume that you have one variable containing the filename for both the IMG SRC and the A HREF fields; the only thing you would need to change is loop through the string, and replace '#' with '%23' before writing the line out the HTML file.
|
|
|
|
Post by Howard Metcalfe on Feb 17, 2008 19:14:45 GMT -5
I did see the path size limit, and since my images are all in the scrapbook (and thus not using full pathnames), that wasn't a problem. PA Writer itself handles the filename conversion fine (or I wouldn't be able to view the wallet images either); it is just browsers trying to reference those filenames that are having the problem. I assume that you have one variable containing the filename for both the IMG SRC and the A HREF fields; the only thing you would need to change is loop through the string, and replace '#' with '%23' before writing the line out the HTML file. Did it an hour ago. Works just fine now for both OS X and OS 9. Will be in version 78. Best, Howard |
|
|
|
Post by lcurtisboyle on Jun 14, 2009 19:33:47 GMT -5
I think we have a regression bug here...any of the long filenames that get OS9ified filename, are no longer exporting at all when writing out HTML. Also, even viewing them in PAWriter itself, it is reporting that it can not find the file (the shortened version of the filename has changed, even the the long OSX one has not?). I can relink it at that point, but it broke quite a few of mine. I just double-checked, and the shortened filenames have changed from the original versions.
|
|
|
|
Post by lcurtisboyle on Jun 14, 2009 19:50:15 GMT -5
One thought on this (I just remembered)... this is the first time I have tried exporting from my new iMac (instead of my old MacBook Pro). I did do the firewire transfer of files, accounts, etc... but would shortened filenames be calculated differently by the OS after being transferred? It may explain my problem.
|
|
|
|
Post by Howard Metcalfe on Jun 15, 2009 17:42:29 GMT -5
One thought on this (I just remembered)... this is the first time I have tried exporting from my new iMac (instead of my old MacBook Pro). I did do the firewire transfer of files, accounts, etc... but would shortened filenames be calculated differently by the OS after being transferred? It may explain my problem. Maybe. I'll look into this again. Best, Howard |
|
