Re: [PEPr] Images::Imagick proposal, Small Errors

> - there are some small coqs: > @ccess > @access > IMAGE_IMAGICK_ERROR_RORATE_FAILED > IMAGE_IMAGICK_ERROR_ROTATE_FAILED > Moreover this constant is not used anywhere, like the other ones. > > - You forgave HTML debug code in addMotionBlur() in the alpha 0.2 Fixed! > - in loadImage() function: > the second parameter for substr() should be the string length, > rather than the end position: > $_sImageName = substr($_sImage, $mTmpPos_1 + 1, $mTmpPos_2 - $mTmpPos_1 - 1); > An there's also a trick on this, sometimes on the web, people don't put any > file extention at all. The more "avant-garde" for this are W3C ;-) > http://www.w3.org/Icons/w3c_home > http://www.w3.org/Icons/WWW/html_48x48 > http://www.w3.org/Icons/valid-xhtml11 > > And if the filename does have a dot in its name? > Yes I know there are a lot of 'if', but the case is possible. > (The php func pathinfo() cannot handle this case neither.) > > far more greedy but should work: > preg_match('!([^/]+?)\.\w{1,5}$!', $this->_sImage, $m); // or an ereg version > $this->_sImageName = $m[1]; > If you shoose to not handle tricky cases, perhaps put a warning in the doc? > to prevent users don't put dots in filenames if they don't put file ext. > (This one won't be 100% perfect too, the only ultim way would put all > extentions in an array and comparing with it.) Well, starting with respecting tricky cases would lead us into the question about usability - there could be a neverending discussion about which errors should be catched and which not. Since I am aware of the fact that errors may occur if a user submits an image-name without a file-extension, I don't want to handle this case. I have put a notice into the doc-block that the file-name MUST have a file extension. (Btw I don't know a case where a user would save an image without file-extension. ) However, if there will be more feedback about this I will think it over. > If you really want to remove all '@' from your code, > perhaps another solution would be to use: > if(file_exists() && is_readable()) {/*safe include*/} Good suggestion, but I do not see an easy way to handle an error without putting @ before the include statement. The problem: The filters may all be saved into the directory PEAR/Image/Filter/. file_exists() Does not know the include_path, and PHP doesn't know the PEAR Directory. You could search the include-paths for the filter, but what if the script finds more than one directory named /Image/Filter with the specific file in it? I know this may not happen too often, but instead of doing a workaround with the include_paths I think this is by far the better (and faster) choice. Thanks for your comment I will handle your other posts now ;) Regards Thorsten