Extension talk:Dia

Q:What does this extension do?
Could you please clarify what does this extension do. It sounds very cool (if I understand correctly), but how does it work? I see that it doesn't simply enable upload of dia files (like it is enabled on wiki e.g. for .xcf files), but you didn't specify what else does it do.

You also didn't say (at least not directly) if I need to have Dia installed for it to work. Correct me if I'm wrong, but it looks like it is needed.

You didn't say what shapes does your extension support and so I assume that your extensions is allowing MediWiki to generate thumbnails directly with the specified size by using Dia scripts.

Best regards,

Nux

A:What does this extension do?
Hi, as you have correctly assumed, this extension allows you to upload dia files directly to MediaWiki. The thumbnails are then automatically generated on-the-fly, as they are for e.g. SVG files.

I'm not sure if your question and the latest update of the Extension:Dia page have crossed, because I realized only after I published the page that I had forgotten to tell that you specifically need to allow .dia files to be submitted. I now tell this in the code snippet where the extension is loaded (see the line below that).

In the advanced configuration you can read that this extension needs an external program to provide the conversion. This is currently done by dia. (Is there anything else that can convert .dia files? I don't believe there is.) This, of course, requires Dia to be installed, but I will make this dependency a bit more explicit.

As to answer your last question, since this extension uses Dia to perform the conversion, it also means that it should support any shape that Dia itself does, meaning, if someone uploads a .dia file that uses an extra plugin or extra shapes, then you will need to install these on the server as well.

Hoping to have answered all your questions, Marcel

How can I display a dia file? (Sintaxis)

Compressed format not working
The extension works fine with MW 1.12 and the documentation is clear enough for patching file (thx for this :). However, I did notice an unexpected problem : the extension doesn't handle .dia file which are compressed. It only process .dia files that are not internally compressed.

It is not a big problem to solve when you understand what is happening, but it could be useful to mention it in the documentation. Also, if there is a way to upload compressed dia files, that could be useful as well ;) LT-P 10:59, 20 May 2008 (UTC)


 * How did you solve the problem? Of course, you can simply unpack it when it is uploaded, but then you do expect that it is always compressed. Did you find a really elegant solution that handles all cases?
 * --Olenz 14:55, 3 July 2008 (UTC)


 * Same problem here. Any solutions yet? How can I handle uncompression at upload time? For now I am running "gzip -dc" on the files before uploading them. As I understand, this is in MediaWiki's MIME type handling, not in the Dia extension itself, am I right?

I fixed this issue on a MediaWiki 1.13.0 installation with the following patch:

--- ./extensions/Dia/Dia.body.php.orig	2007-10-31 14:23:42.000000000 -0400 +++ ./extensions/Dia/Dia.body.php	2008-08-29 10:05:43.000000000 -0400 @@ -5,6 +5,13 @@ 	global $wgDIANominalSize; $xmlstr = file_get_contents( $filename ); + +	# filbranden 2008-08-29: detect gzipped Dia files +	if ( substr($xmlstr, 0, 2) == "\037\213" ) { +		$xmlstr = shell_exec(escapeshellcmd("gzip -dc $filename")); +	} +	# filbranden 2008-08-29: end detect gzipped Dia files + 	$xmlstr = str_replace( "<dia:", "<", $xmlstr ); $xmlstr = str_replace( "</dia:", "</", $xmlstr ); --- ./includes/specials/SpecialUpload.php.orig	2008-07-10 04:32:34.000000000 -0400 +++ ./includes/specials/SpecialUpload.php	2008-08-29 10:49:28.000000000 -0400 @@ -1382,6 +1382,13 @@ 				return false; } +		# filbranden 2008-08-29: accept gzipped Dia files +		if ( $mime == "application/x-gzip" && $extension && strtolower($extension) == "dia" ) { +			wfDebug( __METHOD__.": special handling of compressed Dia files\n" ); +			return true; +		} +		# filbranden 2008-08-29: end handling gzipped Dia + 		$match= $magic->isMatchingExtension($extension,$mime); if ($match===NULL) { --- ./includes/MimeMagic.php.orig	2008-07-02 19:25:20.000000000 -0400 +++ ./includes/MimeMagic.php	2008-08-29 10:53:23.000000000 -0400 @@ -593,6 +593,19 @@ 				$m = NULL; } else { wfDebug( __METHOD__.": magic mime type of $file: $m\n" ); + +				# filbranden 2008-08-29: if file is gzipped but extension is ".dia", treat as a Dia diagram: +				if ( $m == "application/x-gzip" ) { +					if ( $ext === true ) { +						$i = strrpos( $file, '.' ); +						$ext = strtolower( $i ? substr( $file, $i + 1 ) : '' ); +					} +					if ( $ext && strtolower($ext) == "dia" ) { +						$m = "application/x-dia-diagram"; +					} +				} +				# filbranden 2008-08-29: end detection of gzipped Dia diagram. + 				return $m; } 		}

"Cannot allocate memory"
This sounds like a nice extension. Unfortunately, I can't get it to run.

After removing the above problems (MIME types, compressed files, ...), I can now upload diagrams. Unfortunately, when the diagram is about to be rendered, I get the following message in the place where the diagram should be:

Error creating thumbnail: dia: error while loading shared libraries: libXrender.so.1: failed to map segment from shared object: Cannot allocate memory

As of July 3rd 2008, see here.

I've already tried to increase the available memory size for PHP, but to no avail.

Any hints?

--Olenz 14:43, 3 July 2008 (UTC)


 * I have found the problem: the amount of memory given to shell commands is controlled by the configuration variable

$wgMaxShellMemory


 * which is set to 102400 by default. Apparently, 100MB is too few memory for larger diagrams.
 * By setting

$wgMaxShellMemory = 512000;


 * everything goes smoothly now.
 * --Olenz 07:14, 4 July 2008 (UTC)

As you may notice, I have incorporated the above experiences into the Installation section of the article. --Olenz 08:01, 4 July 2008 (UTC)

Size of Dia Image
Hello,

I'm using this extension, and I'm not particularly happy with the way it's calculating the image size by looking inside the XML. Anyway, it seems to be doing the wrong thing, because the numbers inside the XML are floats, and I don't think that they are pixels at all. The size it calculates is always much smaller than the size I get by running "dia -e" without any "-s" parameter.

To work around this, I patched Dia.body.php to use "dia" to calculate the image size. However, this is not very efficient from my point of view, since then it will call "dia" to create a PNG in /tmp only to find the image size and delete it, while just after that it will be called again to generate an image in the thumbnails. I was trying to do it only once, generate an image and set its size attributes later, but I didn't find any way to do it. Do you know how to do that?

Anyway, here is my patch to call "dia" to generate a temporary image and calculate the file size:

--- Dia/Dia.body.php.orig	2007-10-31 14:23:42.000000000 -0400 +++ Dia/Dia.body.php	2008-08-29 16:45:49.000000000 -0400 @@ -156,7 +156,19 @@ 	} 	function getImageSize( $image, $path ) { -		return wfGetDIAsize( $path ); +		#return wfGetDIAsize( $path ); + +		# filbranden 2008-08-29: call Dia and create a png to calculate the size +		# NOTE: this is really wasteful, I would prefer to do that only in doTransform, but I do not know how to do that +		$tmpfile = tempnam("/tmp", "MediaWikiDia"); +		$retval = 0; +		$gis = false; +		wfShellExec("dia -n -e $tmpfile -t png $path", $retval); +		if ($retval == 0) { +			$gis = getimagesize($tmpfile); +		} +		unlink($tmpfile); +		return $gis; } 	function getThumbType( $ext, $mime ) {