Bug with @{file_name} attribute and convert

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
legspeleo
Posts: 1
Joined: 2011-09-15T10:07:50-07:00
Authentication code: 8675308

Bug with @{file_name} attribute and convert

Post by legspeleo »

there is a problem using the @{filename} attribute when drawing text using convert

we have been using it to generate bitmap fonts from a list of characters to be drawn in a text file. As some characters are outside of the ascii scope. i.e unicode, we found it the only way to do it was to draw from a text fiel containing the character to be drawn.

The BUG:

the script we had been using generates a text file which is named as follows

{font_name}_{char_code}-{actual_character_if_valid_filename_char}.txt

we then use imagemagick to then draw the character using from the text file using a command such as:

convert -size 27x31 xc:black -font Arial-Bold-Italic -pointsize 19 -fill gradient:yellow-DarkOrange -gravity Center -annotate 0 @imagesets/in/menu_360/gametext/gametext_202-Ê.txt imagesets/in/menu_360/gametext/gametext_202-Ê.png


I have found that using the following windows binary:

ImageMagick-6.7.2-1-Q16-windows-x64-dll

this now results in the whole filename being drawn instead of the character in the file for all characters that cannot be typed normally using the keyboard (i.e not using the ALT modifier)



it was working fine with previous version 32bit version

ImageMagick-6.6.3-0-Q8-windows-dll


as a workaround we have modified the text filenaming such that the following now works with the 64 bit binary:

convert.exe -size 27x31 xc:black -font Arial-Bold-Italic -pointsize 19 -fill gradient:yellow-DarkOrange -gravity Center -annotate 0 @imagesets/in/menu_360/gametext/gametext_202-u00CA.txt imagesets/in/menu_360/gametext/gametext_202-Ê.png



Regards

Laurence
Jason S
Posts: 103
Joined: 2010-12-14T19:42:12-07:00
Authentication code: 8675308

Re: Bug with @{file_name} attribute and convert

Post by Jason S »

I think the bug is in the FileToBlob function in magick/blob.c. On Windows, instead of calling open(), the parameters need to be converted from UTF-8 to UTF-16, and passed to _wopen() instead.

Note that the problem that caused you to do it this way has been fixed. You can now use arbitrary characters on the command line, so maybe you don't need to make these text files at all.
Jason S
Posts: 103
Joined: 2010-12-14T19:42:12-07:00
Authentication code: 8675308

Re: Bug with @{file_name} attribute and convert

Post by Jason S »

Just wondering if there's a plan to fix this, and similar problems. Since I'm partly responsible for the update that broke it, I feel like I should lobby for it.

I was able to fix this particular issue with a patch like this:

Code: Select all

#if defined(MAGICKCORE_HAVE__WFOPEN)

int open_utf8(const char *filenameUTF8, int oflag, int pmode)
{
	WCHAR *filenameW=NULL;
	int count;
	int ret;

	count = MultiByteToWideChar(CP_UTF8,0,filenameUTF8,-1,NULL,0);
	filenameW = (WCHAR*)AcquireQuantumMemory(count,sizeof(WCHAR));
	count = MultiByteToWideChar(CP_UTF8,0,filenameUTF8,-1,filenameW,count);
	ret = _wopen(filenameW, oflag, pmode);
	RelinquishMagickMemory(filenameW);
	return ret;
}

int access_utf8(const char *pathUTF8, int mode)
{
	WCHAR *pathW=NULL;
	int count;
	int ret;

	count = MultiByteToWideChar(CP_UTF8,0,pathUTF8,-1,NULL,0);
	pathW = (WCHAR*)AcquireQuantumMemory(count,sizeof(WCHAR));
	count = MultiByteToWideChar(CP_UTF8,0,pathUTF8,-1,pathW,count);
	ret = _waccess(pathW, mode);
	RelinquishMagickMemory(pathW);
	return ret;
}

#endif

--------- magick/blob.c

MagickExport unsigned char *FileToBlob(const char *filename,const size_t extent,
  size_t *length,ExceptionInfo *exception)
...
  if (LocaleCompare(filename,"-") != 0)
#if defined(MAGICKCORE_HAVE__WFOPEN)
    file=open_utf8(filename,O_RDONLY | O_BINARY,0);
#else
    file=open(filename,O_RDONLY | O_BINARY);
#endif

--------- magick/utility.c

MagickExport MagickBooleanType IsPathAccessible(const char *path)
...
#if defined(MAGICKCORE_HAVE__WFOPEN)
  if (access_utf8(path,F_OK) != 0)
#else
  if (access(path,F_OK) != 0)
#endif
    return(MagickFalse);
Note that if IsPathAccessible() were changed like this, and nothing else were done, it would probably leave some code that uses it half-baked, and break a few more things.

This is all pretty clumsy, and it would be easier if ImageMagick never directly called standard functions that take filenames (open, fopen, access, stat, unlink, mkdir, ...), but instead called wrapper functions that could do the conversion when needed.
Last edited by Jason S on 2011-09-22T20:01:32-07:00, edited 1 time in total.
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Bug with @{file_name} attribute and convert

Post by magick »

We'll try to get your patch into the next point release of ImageMagick. Thanks.
Post Reply