Extension talk:GraphViz/Archive3

Error Messages and other curious behaviour
I have expected that the diagrams created for the old graphViz extension would also work with the new one. Instead I get an error message: "Error: no valid link was found at the end of line 2".

What does this mean? '''Answer: Extension:ImageMap now handles image rendering on behalf of the GraphViz extension. The "no valid link" message is actually from the ImageMap extension complaining that it doesn't understand the provided link syntax. The old GraphViz extension syntax for specifying an internal link (a bare string without enclosing square brackets) is not natively understood by MediaWiki or the ImageMap extension. If you add two sets of enclosing square brackets (the normal wiki syntax for internal links) you'll be back in business. Please see Extension:GraphViz for more information about the new GraphViz link syntax. P.S. Do you have graphs with a ton of internal links in the old syntax? I dislike the idea of perpetuating a non-standard internal link syntax but if this is a significant hardship then I might consider a backwards compatibility shim. --Thanks, Keith Welter'''

Are there other error messages which should be explained? '''Answer: In addition to returning error messages from Extension:ImageMap, the GraphViz extension also returns error messages from the graphviz and mscgen rendering tools (e.g. about syntax errors in the DOT or Mscgen language input). The GraphViz extension also returns error messages about problems uploading a rendered image (e.g. insufficient permissions or forbidden image type). Finally the GraphViz extension returns error messages about internal errors such as failure to create the working directory. These are the basic categories of error messages. If you see a specific error message and have questions about it, please let me know. --Thanks, Keith Welter'''

Because my own examples didn't work, I tried the first two examples from the extension page. I get a very curious behaviour when putting both examples on one page. Here's the code:

Example 1 from http://www.mediawiki.org/wiki/Extension:GraphViz
 digraph example1 {Hello->"World!"}

Example 2 from http://www.mediawiki.org/wiki/Extension:GraphViz
 graph EXAMPLE2 { run -- intr; intr -- runbl; runbl -- run; run -- kernel; kernel -- zombie; kernel -- sleep; kernel -- runmem; sleep -- swap; swap -- runswap; runswap -- new; runswap -- runmem; new -- runmem; sleep -- runmem; }

The first heading is shown on the left side (correct) The first diagram is presented on the right side. (don't know if this is correct.) Then the second heading is shown under the first diagram and the second diagram is also shown on the right side. (wrong) The second heading and the second diagram should be placed on the left side.

Is this already known? '''Answer: As mentioned above, Extension:ImageMap now handles image rendering on behalf of the GraphViz extension. It does standard MediaWiki image rendering. If you scroll down in the image format table, you'll see that format=frame does yield the image on the right of the screen. Also see, Help:Images I think all the answers to your formatting questions should be on the image page. If not, the talk page for that is the right place to post follow-up questions. --Thanks, Keith Welter'''

Workaround: For now, I have simply removed the  part. Then, there are no borders and both diagrams are shown on the left side.

Thanks, Martin

July 1st, 2014: Thanks Keith for the very fast answer!

I'll try with the new link syntax. I'm generating my diagrams from the results of sparql queries (working with Semantic MediaWiki). This way the diagrams always show the current state of the wiki. So I have only to do some corrections in a few templates. But at first, I'll try to get some hard-coded examples working. I'll share my experiences here. And I'll take a closer look at the ImageMap extension. Thanks for the explanations on that.

''I have experimented further and I now see that there is another problem at the bottom of it. Even when I removed all links I got the error message with the link. And this was really confusing. But now I have seen this: when I change a graph without changing its name it is not re-rendered. I have now started with the simple "Hello, World" example and only added a second line to the DOT code:. When saving the page the old diagram is shown. When changing the name to something not used before, the new diagram will be created. I'm sure that this works for you, so I think I'm doing something wrong. Where can I look for debugging this?''

'''Hi Martin, I'm seeing the same problem on MW 1.22.2. Please open a bug (I'll be debugging in the meantime). The edit preview does still work for me. So you can try that to see how your rendered graphs look. Just click on the "Show preview" button on the edit page.

'''Actually, I just installed GraphViz version 1.3.0 and if I reload the page after clicking save then I see the rendering of the updated graph. Please try that and report back with your results (along with your MW version and GraphViz version which you can find on the Special:Version page of your wiki. Caching may be a factor so please also provide the $wgMainCacheType value from your LocalSettings.php.

'''For debugging, see Manual:How_to_debug. I use the following in my LocalSettings.php: $wgDebugLogFile = "/var/log/mediawiki/debug-{$wgDBname}.log"; $wgDebugToolbar = true; $wgShowExceptionDetails = true; $wgDevelopmentWarnings = true;

'''The GraphViz extension uses wfDebug statements to produce debug log entries which include the function name. You can search for names like "GraphViz::", "GraphRenderParms::" and "UploadLocalFile::".

'''--Thanks, Keith Welter

Hello Keith,

I wanted to try version 1.3.0 before filing a bug report but I couldn't download it. I have still MediaWiki 1.19.17 and therefore followed the git link. There I still get the version 1.1.0 from June 27th. I have even emptied my browser cache and downloaded again, same result. Perhaps due to caching at www.mediawiki.org???

Talking of caching: I'm using the default CACHE_NONE for my wiki.

And the extension works fine as long as I'm not updating the dot code. Even my templates work now. (so "Thanks!" again!)

Another point: when having finished this discussion I would look over this and keep only the essentials which may be of importance for other users. Is this OK for you?

Best regards, Martin

'''Hi Martin, I recreated the problem on MW 1.19.17. The problem is that the extension uses two hooks that were introduced in MW 1.21. There are alternative hooks (deprecated in MW 1.21) that should work for MW versions <1.21. I'll begin work on the backward compatibility fix. Please do proceed with opening the bug. Also, I agree about cleaning-up this talk page when we're done. And feel free to suggest any improvements for the doc on the main extension page. --Thanks, Keith Welter'''

Hello Keith,

I have filed the bug now. It's number 67587. And thanks for addressing the backward compatibility issue. Despite the newer versions of MediaWiki the 1.19.17 is a long-term stable one and there are still a lot of people using it. --Best regards, Martin

Preview
Every time a new graph is added to the page or an old one is edited, on preview or page save, instead of the graph, an inscription appears: ''Graph image source changed. Reload page to display updated graph image.'', and you need to press F5 to see the graph. It was not like this in previous versions of the extension. This is very uncomfortable since it renders the Preview button useless, and a graph is not something you can make perfect on the first attempt.

Alex Mashin (talk) 07:33, 20 July 2014 (UTC)

Hi Alex. First off, sorry for the slow response. This page is on my watch list but I didn't get notified (or it went to my spam folder which only goes back to August). I'll endeavor to remove the reload behavior in a future version (it requires a substantial design change so it will probably be version 2.x.x). Another apology-- I'm effectively on paternity leave so it will be some time before I can get to this. Thanks for your feedback and sorry the reload behavior is not to your liking. BTW, pressing F5 to reload the graph image on the preview page works for me to see graph changes reflected before saving them. --Welterkj (talk) 21:57, 18 September 2014 (UTC)

Hi Alex, I've released version 1.4.0 which avoids the reload message in most cases. Please give it a try and let me know how it goes. Thanks! --Welterkj (talk) 19:21, 19 October 2014 (UTC)

Dynamic Graphs
I've been using earlier versions of this extension for some time to generate GraphViz code and replace text/colors in the code with live status from a database to produce live network diagrams based on our monitoring systems. This recent update appears to have broken that ability. What I'd done was to have something like this in a page:

 graph { A [label=< ]; B [label=< ]; A -- B [taillabel="1",headlabel="2",color=";{{MyPort:B:2]]"]; } 

My extension takes this tag input and replaces the patterns it finds in the content with icons that represent the state of the HOST. The patterns get replaced with a color that reflects the interface state of the PORT on the HOST. The output of the extension is a tag with the tags replaced then sent back through $parser->recursiveTagParse. The tag is also calling $parser->disableCache so the results are updated for each request.

This has worked well for many years until last week when I updated a DEV machine to the new release of this extension. Seems the new approach to storing the generated images as true file articles in MediaWiki is messing with me. I thought I'd reach out and see if there's some nice way to fix this or if I should just stick with the older code.

Thanks in advance.

PDugas (talk) 14:34, 28 July 2014 (UTC)

Hi PDugas. Please see my response to Alex about the "Preview" issue above. I suspect you are running afoul of the same reload behavior that Alex dislikes. I suggest you stick with the older code until the new version I described to Alex is available. Sorry the current version isn't working for you. --Welterkj (talk) 22:02, 18 September 2014 (UTC)

Hi PDugas, after more thought, I think the dynamic graph functionality you describe would require a new feature in the GraphViz extension (>1.0). I'll do some more investigation. --Welterkj (talk) 19:23, 19 October 2014 (UTC)

Dynamic graph functionality is now available at the development level (use "composer require mediawiki/graph-viz 'dev-master'"). Usage: ... . You can also specify preparse="static" which will only replace variables/templates when saving or previewing an edit of the page containing the (or ) tags. --Welterkj (talk) 20:34, 26 October 2014 (UTC)

The preparse tag argument is now available in version 1.5.0. --Welterkj (talk) 21:25, 28 October 2014 (UTC)

Does not always work with me: With dynamic as well as static setting of the preparse argument. edit: at times it appears to be working, though it is difficult to make out the reason why, because on another occasion it refuses to do so and throws out a considerable amount of errors messages.--Temptuousinsolence (talk) 15:04, 31 October 2014 (UTC)

Hi Temptuousinsolence, please raise a bug under component "[other]" and provide the wikitext that caused the problem as well as a debug log. Thanks. --Welterkj (talk) 16:02, 31 October 2014 (UTC)--

Bugfix Version 1.3.1 (2014-07-10)
Hi, I don't know how to report this on https://bugzilla.wikimedia.org because the extension is not listed there, so I report this here: Here is a patch: --Andreas P. 11:24, 7 August 2014 (UTC)
 * the contruction of the class GraphVizSettings is wrong and stops the Wiki from functioning. (I use MediaWiki 1.23.2, PHP 5.4.20 (fpm-fcgi), MySQL 5.6.12-log)

Hi Andreas. The existing code works fine for me on MW 1.23.2. Can you be more specific about the symptoms of your problem? It seems to me that with your patch $wgGraphVizSettings would only be visible within the local scope of the anonymous function that contains it (though it is meant to be global scope). Thanks. --Welterkj (talk) 22:27, 18 September 2014 (UTC)

I had the same problem and it helps at least to get rid of the error message in line 81 of the Graphviz.php: The symptom is that there is a persistent error message that does not want to vanish. --Temptuousinsolence (talk) 10:16, 21 October 2014 (UTC)

I reproduced the problem and raised bug 72325 (component [other] is fine for GraphViz bugs). Thanks! --Welterkj (talk) 18:04, 21 October 2014 (UTC)

Fixed in version version 1.4.1. --Welterkj (talk) 04:03, 22 October 2014 (UTC)

Specific example?
The link given the for example is a link to the gallery for the Graphviz library, not Extension:GraphViz itself. Is there a demo site where this extension is running? If a live demo site isn't available, maybe show some screenshots/PDFs of the page source showing Graphviz syntax and the resulting output. --Lance E Sloan 17:39, 16 September 2014 (UTC)

Hi Lance. I changed the link to point to Extension:GraphViz. If I find a good live demo site I'll update it again. Thanks. --Welterkj (talk) 22:10, 18 September 2014 (UTC)

GraphViz 1.5.0 internal error with MW 1.23.6
I run MW 1.23.6. GraphViz 1.3.1 works fine. But when I upgrade GraphViz extension (using composer) to 1.5.0, I get following "Internal error" when opening a page with embeded graphs or try to create a new graph: [exception] [107987dc] /mediawiki/index.php?title=Sandbox&action=submit Exception from line 77 of /srv/www/htdocs/mediawiki/includes/parser/StripState.php: Invalid marker: ^?UNIQ9f35223a283f1154-graphviz-00000001-QINU^? Anybody having the same issue? --Ralfk (talk) 12:39, 31 October 2014 (UTC)

Yes, I have the same issue. Preparsing (see a bit above) makes it at least possible to edit the page and enter the content to the MW-page, but the current GraphViz extension is hardly working smoothly. --Temptuousinsolence (talk) 15:06, 31 October 2014 (UTC)

Hi guys, sorry for your trouble with GraphViz 1.5.0 and MW 1.23.6. I did my testing on MW 1.23.2 and MW 1.19.20 so I'll upgrade the former and try to reproduce. In the meantime, please raise a bug under component "[other]" and provide a debug log. Thanks. --Welterkj (talk) 15:55, 31 October 2014 (UTC)

I have setup xdebug and will upload a log file once I have configured it properly.--Temptuousinsolence (talk) 10:11, 4 November 2014 (UTC)

I got some time to investigate today and it appears that the contents of the git repository are not what they should be. So please disregard the request for a debug log file while I sort-out what happened with the relevant commits. To revert to a stable version: Sorry again for the inconvenience. --Welterkj (talk) 00:13, 5 November 2014 (UTC)
 * I have changed the GraphViz-Version, but still the same error.--Temptuousinsolence (talk) 13:41, 5 November 2014 (UTC)

I had tagged the wrong commit when I created release 1.5.0 for composer. That is fixed now so uninstalling/installing version 1.5.0 will now result in the correct code being installed. To uninstall, I delete the require graph-viz line out of the composer.json file in the MW installation dir and then do 'composer update'. I tested a composer install of the fixed version 1.5.0 on MW 1.23.6 and that worked fine for me (version 1.4.1 also works for me). Please reinstall version 1.5.0 and if you still have trouble we should really open a bug report and move the conversation there. I'm happy to do that if needed. Thanks. --Welterkj (talk) 20:29, 5 November 2014 (UTC)
 * What has changed is that the amount of errors has increased ...
 * for instance:

the ">" is not parsed correctly of the mscgen. I thought that maybe there was an error in the permissions, since I am on a Linux machine and played around with them and now I have an even longer trail of error codes ... Bugreport --Temptuousinsolence (talk) 09:39, 6 November 2014 (UTC)
 * I uninstalled the extension (even though this wiki was on 1.3.1 before) and installed it again as 1.5.0. But still the same error (and even one additional) --Ralfk (talk) 14:22, 6 November 2014 (UTC):

[Bug56269] Exception thrown with an uncommited database transaction: [8d1f035a] /wiki/Sandbox/Graphviz  Exception from line 77 of /srv/www/htdocs/w/includ es/parser/StripState.php: Invalid marker: ^?UNIQbc7b8602bc553993-graphviz-00000003-QINU^?

[exception] [8d1f035a] /wiki/Sandbox/Graphviz  Exception from line 77 of /srv/www/htdocs/w/includes/parser/StripState.php: Invalid marker: ^?UNIQbc7b8602b c553993-graphviz-00000003-QINU^?

Alex Mashin (talk) 11:30, 8 November 2014 (UTC)
 * I confirm that the invalid marker error is still there as of today.Alex Mashin (talk) 10:53, 8 November 2014 (UTC)
 * After downgrading to 1.4.1 and 1.4.0, the error persists. 1.3.1 works, more or less.

I need a debug log to diagnose this problem since I am unable to reproduce it. If someone could attach a log to the bug report that would be a big help. -Welterkj
 * I uploaded a log ... I had been busy lately and did not have had the time to deal with this. --Temptuousinsolence (talk) 08:53, 13 November 2014 (UTC)

preparse
What is wrong with ? Alex Mashin (talk) 11:30, 8 November 2014 (UTC)
 * Hi Alex. I don't understand your comment.  GraphViz has always been implemented as a tag extension.  Are you requesting a new feature whereby the extension would also support a parser function alternative syntax?  --Welterkj (talk) 18:31, 1 December 2014 (UTC)

Polynomial explosion when used in templates
This extension creates articles in the File namespace, one per image. This is fine. But if you use the extension in a template, and 100 pages transclude the template, you get 100 identical images in the File namespace. And every time you update the template, potentially 100 uploaded files get replaced... all identical! That seems a fundamentally questionable design decision.

Is there a way around this non-scalable behavior? --Maiden taiwan (talk) 20:43, 21 November 2014 (UTC)

Hi Maiden. You should be able to create the graph once using tags outside of the template and then use image syntax to refer to the graph image generated by GraphViz. If the graph contains links, you can use ImageMap syntax instead. In this case, the file page for the graph image will include the ImageMap wikitext that you can copy and paste into your template definition. You can modify the Image line of the copied ImageMap wikitext with different layout options if you want. Cheers. --Welterkj (talk) 18:15, 1 December 2014 (UTC)

Call to a member function getId on a non-object
When GraphViz first creates its File page, we are seeing this error:

PHP Fatal error: Call to a member function getId on a non-object in /path/w/extensions/GraphViz/GraphViz_body.php on line 351

Here's the line:

return $title->getLatestRevID != $title->getFirstRevision->getId;

So getFirstRevision is null, perhaps because the File page hasn't been created yet? Should this be:

return $title->getFirstRevision ? $title->getLatestRevID != $title->getFirstRevision->getId : false ;

MediaWiki bug tracker is down this week for an upgrade, so I'm reporting the problem here. Any workarounds?

--Maiden taiwan (talk) 20:54, 21 November 2014 (UTC)


 * Possible. But maybe it is related to the issue that is brought oup here. I somehow recall that I had problems with the id once as well, but it had been in a different environment that I am currently working with. --Temptuousinsolence (talk) 09:24, 24 November 2014 (UTC)
 * Please raise a bug. Thanks.  --Welterkj (talk) 18:25, 1 December 2014 (UTC)

Latest "stable" GraphViz under MW 1.24
This happens hen MW tries to parse a page with a  tag: [e4fa625c] /wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Alex_Mashin/%D0%9F%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0 Exception from line 6347 of (skipped)/includes/parser/Parser.php: Parser state cleared while parsing. Did you call Parser::parse recursively?

Backtrace:


 * 1) 0 (skipped)/includes/parser/Parser.php(4752): Parser->lock
 * 2) 1 (skipped)/includes/content/WikitextContent.php(146): Parser->preSaveTransform(string, Title, User, ParserOptions)
 * 3) 2 (skipped)/includes/page/WikiPage.php(2140): WikitextContent->preSaveTransform(Title, User, ParserOptions)
 * 4) 3 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/EditInfoProvider.php(88): WikiPage->prepareContentForEdit(WikitextContent, NULL, User, string)
 * 5) 4 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/EditInfoProvider.php(66): SMW\MediaWiki\EditInfoProvider->prepareContentForEdit
 * 6) 5 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/Hooks/NewRevisionFromEditComplete.php(81): SMW\MediaWiki\EditInfoProvider->fetchEditInfo
 * 7) 6 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/Hooks/NewRevisionFromEditComplete.php(76): SMW\MediaWiki\Hooks\NewRevisionFromEditComplete->getParserOutputFromEditInfo
 * 8) 7 (skipped)/extensions/SemanticMediaWiki/includes/Setup.php(392): SMW\MediaWiki\Hooks\NewRevisionFromEditComplete->process
 * 9) 8 [internal function]: SMW\Setup->SMW\{closure}(WikiFilePage, Revision, integer, User)
 * 10) 9 (skipped)/includes/Hooks.php(206): call_user_func_array(Closure, array)
 * 11) 10 (skipped)/includes/GlobalFunctions.php(3995): Hooks::run(string, array, NULL)
 * 12) 11 (skipped)/includes/filerepo/file/LocalFile.php(1424): wfRunHooks(string, array)
 * 13) 12 (skipped)/includes/filerepo/file/LocalFile.php(1184): LocalFile->recordUpload2(string, string, string, array, boolean, User)
 * 14) 13 (skipped)/includes/upload/UploadBase.php(738): LocalFile->upload(string, string, string, integer, NULL, boolean, User)
 * 15) 14 (skipped)/extensions/GraphViz/UploadLocalFile.php(238): UploadBase->performUpload(string, string, boolean, User)
 * 16) 15 (skipped)/extensions/GraphViz/GraphViz_body.php(1140): UploadLocalFile::upload(string, string, User, string, string, boolean, boolean)
 * 17) 16 (skipped)/extensions/GraphViz/GraphViz_body.php(740): GraphViz::render(string, array, Parser, PPFrame_DOM)
 * 18) 17 [internal function]: GraphViz::graphvizParserHook(string, array, Parser, PPFrame_DOM)
 * 19) 18 (skipped)/includes/parser/Parser.php(4156): call_user_func_array(array, array)
 * 20) 19 (skipped)/includes/parser/Preprocessor_DOM.php(1262): Parser->extensionSubstitution(array, PPFrame_DOM)
 * 21) 20 (skipped)/includes/parser/Parser.php(3281): PPFrame_DOM->expand(PPNode_DOM, integer)
 * 22) 21 (skipped)/includes/parser/Parser.php(1239): Parser->replaceVariables(string)
 * 23) 22 (skipped)/includes/parser/Parser.php(405): Parser->internalParse(string)
 * 24) 23 (skipped)/includes/content/WikitextContent.php(338): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)
 * 25) 24 (skipped)/includes/content/AbstractContent.php(490): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)
 * 26) 25 (skipped)/includes/poolcounter/PoolWorkArticleView.php(139): AbstractContent->getParserOutput(Title, integer, ParserOptions)
 * 27) 26 (skipped)/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork
 * 28) 27 (skipped)/includes/page/Article.php(688): PoolCounterWork->execute
 * 29) 28 (skipped)/includes/actions/ViewAction.php(44): Article->view
 * 30) 29 (skipped)/includes/MediaWiki.php(414): ViewAction->show
 * 31) 30 (skipped)/includes/MediaWiki.php(282): MediaWiki->performAction(Article, Title)
 * 32) 31 (skipped)/includes/MediaWiki.php(584): MediaWiki->performRequest
 * 33) 32 (skipped)/includes/MediaWiki.php(435): MediaWiki->main
 * 34) 33 (skipped)/index.php(46): MediaWiki->run
 * 35) 34 {main}


 * Graphviz	1.5.0 (version 30798c3) 03:46, October 29 2014
 * ImageMap	(version 634ad79) 04:03, November 25 2014
 * MediaWiki 	1.24.0 (ebb1639) 08:36, November 27 2014.
 * You may want to try this version of GtraphViz: https://gerrit.wikimedia.org/r/#/c/174487/ It worked for me with the 1.23 version ... care to check whether it runs with 1.24 as well? --Temptuousinsolence (talk) 10:40, 1 December 2014 (UTC)
 * I agree that this is most likely another symptom of bug T75073. Please read the comments of that bug before testing the fix.  Thanks.  --Welterkj (talk) 18:19, 1 December 2014 (UTC)
 * I have just tested it ... runs fine. I have even been able to edit it wiht the Visual Editor, which is quite convenient if you ask me. --Temptuousinsolence (talk) 08:42, 2 December 2014 (UTC)

Encoding issues
 msc { Ä,Ö,Ü, ä, ö, ü, ß;

ä->ä [label="ä"]; ö->ö [label="ö"]; ü=>ü [label="ü"]; ß=>ß [label="ß"]; Ä=>Ä [label="Ä"]; Ö=>Ö [label="Ö"]; Ü<<=Ü [label="Ü"]; } Is there anything that can be done in terms of the extension to deal with this issue? It appears as if it had been brought up here, but this discussion dates back to 2009 and not much appears to have been changed since.

According to the changelog it should actually be fixed ... strange.--Temptuousinsolence (talk) 10:52, 3 December 2014 (UTC)
 * I tried this on my system (with mscgen version 0.20) and got the following error:

Is this the same error message you see? Then I went to the images/graphviz directory and used the "file -i" command to display the encoding of an msc.src file that is accepted (i.e. no non-ascii characters). I see this: So, it looks like the file that the GraphViz extension is providing as input to the mscgen command is not UTF-8 encoded. Feel free to open a bug and I'll investigate further. Thanks. --Welterkj (talk) 03:10, 8 December 2014 (UTC)
 * Yes, this is exactly the same error. The curious thing is that GraphViz works fine, while mscgen throws an error; it is the one you have posted above. I should have posted it in the first post of mine. Yes, I will open a bug. --Temptuousinsolence (talk) 08:22, 8 December 2014 (UTC)
 * Here's an example that works:

 msc { A,O,U,a,o,u,B;

a->a [label="ä"]; o->o [label="ö"]; u=>u [label="ü"]; B=>B [label="ß"]; A=>A [label="Ä"]; O=>O [label="Ö"]; U<<=U [label="Ü"]; } Perhaps mscgen only accepts non-ascii characters as labels. The encoding of the resulting file is correct in the file system: file -i Main_Page_msc_1.src Main_Page_msc_1.src: text/plain; charset=utf-8 I suggest asking the mscgen maintainer if this behavior is by design. Thanks. --Welterkj (talk) 15:32, 8 December 2014 (UTC)
 * Yes, it works indeed. Strange that that a character in the title fields still throws exceptions, while the program appears to be perfectly fine once they appear somewhere else. Still, this should be fixed somehow. Maybe the mscgen maintainer had forgotten about the fields in the head of the graphs. --Temptuousinsolence (talk) 15:41, 8 December 2014 (UTC)

Why does this extension create category pages?
I am wondering why this extension automatically creates some category pages in the wiki (since version 1.5.0). These pages are listed by other extensions which list category pages (examples: WikiCategoryTagCloud, DynamicPageList). This may be interesting for wiki administrators, but for readers of a wiki it may be confusing. Some extensions allow for an explicit exclusion of pages from their listings - this however requires additional administration work. Kappa (talk) 19:58, 21 December 2014 (UTC)
 * Hi Kappa. I'm assuming you've already read the GraphViz category documentation.  The extension creates category pages so that it is easy to find the graph images generated by the extension (and by renderer).  Here is the back-story.  A user on this talk page asked for a link to a demo site.  I didn't have time to create and maintain a demo site of my own so I went to wikiapiary to look for a public site that was using GraphViz.  Next I visited all of the sites with a recent version and tried to find GraphViz generated graphs.  I spent a lot of time manually searching but didn't find any graphs.  That was frustrating and in my mind exposed a missing feature.  I realized that categories would be a great solution for organizing graph images and making them easy to find.  On a demo site with lots of graphs it would be perfect-- just put a link to Category:GraphViz from the main page and you'd see a master gallery of all the graph images without any manual editing.  You could also navigate to a subcategory and see a gallery dedicated to each renderer (again, no manual editing).  But I think what you're really asking is why does the extension create empty category pages.  That is because it was easy to implement it that way.  I suspect you would prefer that the extension create the category pages on demand rather than preemptively.  I do think that would be an improvement.  Let me know what you think.  Thanks.  --Welterkj (talk) 17:26, 22 December 2014 (UTC)