Image Handler 2 (for ZC v1.3.8 ONLY) Support

[DivaVocals]

I can confirm this, since I just checked my download version of 8c.

I concur.. However, since you both have downloaded the file this weekend, I did update it to remove both the classic and the default_template folders.. I have not yet updated the readme since I am waiting for some last bit of feedback from testers.. (kinda a formality at this point since it's been confirmed that the targeted fixes do in fact work..)

Sorry for the confusion..

[tpeck]

I have a reputation of arrogance and rudeness to maintain.

Keep it up - it's working for you.

Additionally I am of the opinion that "fixing" the IH2 code to allow for these symbols to be used in files names is an inherently BAD idea. Perhaps some of the developers who post here could weigh in on this thought.

Forgetting for a moment the particular issue of bracketing in filenames, it's clearly an inherently bad idea for users to incur errors of any sort that are preventable. Otherwise 99.5% of commercial software marketers would place less weight on user-friendliness than pleasing their purist IT teams. They don't.

You don't sell many vacuum cleaners if they malfunction when passing over plastic rugs because the manufacturer prefers shagpile.

Diva Darling,
Goodness gracious!
Allowing for special characters that are used in our cherished Unix systems to be used in file names?
That would mean an aberrant mix between plebeian files and our noble kernel files, horrid spawns would ensue, often called "errors".
Arrogantly and pompously yours,
ckosloff

I realise you are not trying to sell this product - if you were you would spellcheck the docs for a start - but I'll wager that a lot of current and potential users will be happier when you see the sense in applying the same standards that commercial software sees fit to apply - even when it goes against the grain.

Perhaps this applies to Zencart in general if similar errors occur elsewhere. They are usually eradicated in the best commercial software for very good economic reasons and is an inherently good thing. I'm making a distinction here between "bugs" and deliberately accepting errors and displaying them.

[clydejones]

Forgetting for a moment the particular issue of bracketing in filenames, it's clearly an inherently bad idea for users to incur errors of any sort that are preventable. Otherwise 99.5% of commercial software marketers would place less weight on user-friendliness than pleasing their purist IT teams. They don't.

This may help the debate on filenames

www.controlledvocabulary.com/imagedatabases/filename_limits.html

it clearly states that

Other forms of punctuation such as / \ : ! @ # $ % ^ < > , [ ] { } & * ( ) + = may have specific uses with various operating systems and create confusion or errors.

[tpeck]

Of course I understand the point you are making - and it's a good one up to a point, but why do Picasa, ThumbsPlus, ACDSee, adnausem and even Windows not display such errors in the same circumstance?

OK, so you are arguing for cross-platform solutions. Absolutely, and zencart should attempt to function similarly *without error* on all platforms unless there are specific reasons why this cannot be done.

I don't see this as an issue about filenaming per se, but about stepping up to the plate vis-a-vis standards. This battle was won long ago in the marketplace.

[DivaVocals]

Even in commercial software allowing special characters in file names is a BAD idea.. (which is why Microsoft and Adobe/Macromedia do not recommend using special characters in filenames either)

This is not about pleasing any IT purists, it's about BEST practices. Which is likely why the Zen Cart FAQ makes the same recommendation with regards to special characters, and does not "fix" the Zen Cart code to accept special characters in image filenames (which should not be included in filenames in the first place..)

It's been explained why these characters could not and should not be used. You do not agree with this, and that's fine.. We will have to agree to disagree.. If someone comes along to "fix" this, then great, but the upcoming IH2 release will not include code which allows special symbols to be used in image file names because the core Zen Cart code does not recommend this, and its not a recommended idea to use special characters in filenames.


http://msdn.microsoft.com/en-us/libr...ng_conventions

Naming Conventions

The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:

• Use a period to separate the base file name from the extension in the name of a directory or file.
• Use a backslash (\) to separate the components of a path. The backslash divides the file name from the path to it, and one directory name from another directory name in a path. You cannot use a backslash in the name for the actual file or directory because it is a reserved character that separates the names into components.
• Use a backslash as required as part of volume names, for example, the "C:\" in "C:\path\file" or the "\\server\share" in "\\server\share\path\file" for Universal Naming Convention (UNC) names. For more information about UNC names, see the Maximum Path Length Limitation section.
• Do not assume case sensitivity. For example, consider the names OSCAR, Oscar, and oscar to be the same, even though some file systems (such as a POSIX-compliant file system) may consider them as different. Note that NTFS supports POSIX semantics for case sensitivity but this is not the default behavior. For more information, see CreateFile.
• Volume designators (drive letters) are similarly case-insensitive. For example, "D:\" and "d:\" refer to the same volume.
• Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following:
  
  • The following reserved characters:
    
    • < (less than)
    • > (greater than)
    • : (colon)
    • " (double quote)
    • / (forward slash)
    • \ (backslash)
    • | (vertical bar or pipe)
    • ? (question mark)
    • * (asterisk)
    
    
  • Integer value zero, sometimes referred to as the ASCII NUL character.
  • Characters whose integer representations are in the range from 1 through 31, except for alternate streams where these characters are allowed. For more information about file streams, see File Streams.
  • Any other character that the target file system does not allow.
  
  
• Use a period as a directory component in a path to represent the current directory, for example ".\temp.txt". For more information, see Paths.
• Use two consecutive periods (..) as a directory component in a path to represent the parent of the current directory, for example "..\temp.txt". For more information, see Paths.
• Do not use the following reserved device names for the name of a file:
  CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended. For more information, see Namespaces.
• Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp".

Short vs. Long Names

A long file name is considered to be any file name that exceeds the short MS-DOS (also called 8.3) style naming convention. Typically, Windows stores long file names on disk as special directory entries, which can be disabled systemwide for performance reasons depending on the particular file system. When you create a long file name, Windows may also create a short 8.3 form of the name, called the 8.3 alias, and store it on disk also. This 8.3 aliasing can be disabled for a specified volume.

http://www.records.ncdcr.gov/erecord...0508_final.pdf

Rule #1: Avoid using special characters in a file name. \ / : * ? “ < > | [ ] & $ , .
The characters listed above are frequently used for specific tasks in an electronic environment. For example, a forward slash is used to identify folder levels in Microsoft products, while Mac operating systems use the colon. Periods are used in front of file-name extensions to denote file formats such as .jpg and .doc; using them in a file name could result in lost files or errors.
Rule #2: Use underscores instead of periods or spaces.
As mentioned above, periods already have a specific function in a file name, which is to tell the computer program where the file-name extension begins. Spaces are frequently translated in a Web environment to be read as “%20”. For example,
Naming tutorial.doc

would appear as

Naming%20tutorial.doc

if it were available online. This alteration can cause confusion in identifying the actual file name.

Spaces in file names can also cause broken links, because word processing tools like Microsoft Word, and e-mail clients like Microsoft Outlook, recognize spaces as an opportunity to move to another line. Therefore, a link to
\\Ah1\Intranet\ar\naming conventions

could become

\\Ah1\Intranet\ar\naming
conventions

Another difference that is found among operating systems and software is the acceptable length of file names. Some systems allow up to 256 characters, while others allow far fewer.

[tpeck]

Even in commercial software allowing special characters in file names is a BAD idea.

If someone comes along to "fix" this, then great, but the upcoming IH2 release will not include code which allows special symbols to be used in image file names because the core Zen Cart code does not recommend this, and its not a recommended idea to use special characters in filenames

But in the case of filenames that are accepted by the OS, it doesn't prevent commercial software from functioning.

No-one is asking you or anyone else to fix this immediately or ever if that's your decision - we are debating whether it's a worthy thing to do. If you tried to sell this product in the marketplace and an error popped up without even an error code, it would get the kind of commercial reception it deserves.

BTW agreeing to disagree doesn't mean that all the ideas have been floated in a debate.

[DivaVocals]

But in the case of filenames that are accepted by the OS, it doesn't prevent commercial software from functioning.

Sure it does.. Try using one of the special characters Microsoft forbids in a Microsoft Word document, and let me know what error message you get.

No-one is asking you or anyone else to fix this immediately or ever if that's your decision - we are debating whether it's a worthy thing to do. If you tried to sell this product in the marketplace and an error popped up without even an error code, it would get the kind of commercial reception it deserves.

On the contrary.. Microsoft is doing just fine. Microsoft Office still doesn't allow certain special characters in their filenames..

BTW agreeing to disagree doesn't mean that all the ideas have been floated in a debate.

I haven't seen any new ideas floated.. So at this point I still respectfully still disagree with your viewpoint on this matter.

[tpeck]

Don't take it from me - you can try it yourself:



Save a .doc(x) file with slashes or an asterisk and that's what you get.

If, however, you save a file without receiving an error, the inference is that the filename is valid. This, in and of itself, does not mean it won't fall over elsewhere, but Office - being a sufficiently well-developed piece of software has no issues with it.

Moreover, a more advanced filehandler than IH2 will have no problems at all with any image saved with a filename that .doc(x) accepts.

[DivaVocals]

Moreover, a more advanced filehandler than IH2 will have no problems at all with any image saved with a filename that .doc(x) accepts.

and if someone decides to update IH2 to add this functionality then they will.. For now IH2 will not include any functionality which would allow special characters in filenames.. (and for the record the Zen Cart core code doesn't support this either.. hence the FAQ on this SAME matter..)

No disrespect, but this discussion is now bordering on beating a DEAD horse.. So personally I am kinda done with this discussion.. You all carry on if you wish..

[tpeck]

*No disrespect* isn't what you do. I'm still offended (with no apology) by your personal attacks on me. I don't agree to disagree that you are an offensive individual.

I also believe that you are incapable of extended discussion.

Which is why I am not alone in feeling discomfort in this thread.

But I am always willing to debate anyone. It's a pity you ward off others who can't be bothered with your top-down attitude.

They might shed light on something even *you* don't know.