roberthorlings / pchart4mw Goto Github PK

What steps will reproduce the problem?
1. Running WampServer2 with: Apache 2.2.21, MySQL 5.5.16 & php5.3.8
2. Insert a chart into a page:(using the example from the MediaWiki page)
{{#pPie: exploded|3d|data=
Sales,43
Marketing,21
Development,56
Customer Support,23
Information Technology,31
Administration,13
}}

3. Preview the page

What is the expected output? What do you see instead?
Expected output should be clear of any errors. 
Instead shows the following:
Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

Deprecated: Function split() is deprecated in 
C:\wamp\apps\mediawiki-1.18.1\extensions\pchart4mw\pChart\pChart.class on line 
282

What version of the product are you using? On what operating system?
pChart4mw v1.3.3.zip on Windows Server 2008 with WampServer 2 (as listed above)

Please provide any additional information below.
All listed above

Current situation?
When trying to create a line graph with a large amount of data, e.g.:
    1,foo
    2,foo
    3,foo
    ...
    300,foo
    301,foo
the x-axis labels become overlaid ontop of each other until all you get is a 
grey line - i.e. there is no setting to say "show 5 x labels", giving me just 
"0, 100, 200, 300, 400, 500", on the x-axis. The extension seems to be 
hardwired to show every x-label as it has been entered in to the data.

Requested situation?
Is it possible to implement a new parameter: skiplabels=x

Use pcharts function drawScale function using this new parameter

I like the pchart4mw extension very much. The reason is that I think the way 
the extension works is the way to go. The fact that the data is included in the 
wiki page means that charts can be modified by updating the data rather than 
drawing a new chart from scratch (or trying to remember where you stored that 
spreadsheet). 

However, in my work I need to be able to draw log-log plots (e.g. the show 
scalability of parallel applications). Not being able to tell pchart4mw that I 
want logarithmic scales on my x- and y-axis means that I cannot use the 
extension. Hence I am stuck with the clunky procedure of generating chart 
images and uploading them to the wiki. 

Is there anyway this could be fixed?

What steps will reproduce the problem?
1. Install as directed.
2. Set up a wiki page: Test:PChart4mw
3. Paste in the simplest example you provided and click on "Show preview"
   <pbars>
   5345
   3452
   7843
   </pbars>

What is the expected output? What do you see instead?
Expected: the graph shown at 
http://code.google.com/p/pchart4mw/wiki/YourFirstGraph
Actual: blank white page. Checking the logs reveals the following:
    [Mon Aug 29 18:41:14 2011] [error] [client 10.1.1.2] PHP Fatal error:  Call to undefined function imageftbbox() in /Library/WebServer/EcoReality/mediawiki-1.16.2/extensions/pChart4mw/library.inc.php on line 42, referer: http://www.ecoreality.org/wiki?title=Test:PChart4mw&action=edit


What version of the product are you using? On what operating system?
pChart4mw: Latest (1.3.3) available on this site. The PHP config page reveals I 
have gd
OS: MacOS 10.6.8
PHP: 5.3.4 (as supplied by MacOS 10.6.8)
GD: 2.0.34 (as supplied by MacOS 10.6.8)

Please provide any additional information below.

The missing function imageftbbox() appears to have to do with text rendering. 
How do I tell if I have "freetype extension" installed? It doesn't appear on 
the php config page:

   GD Support   enabled
   GD Version   bundled (2.0.34 compatible)
   GIF Read Support enabled
   GIF Create Support   enabled
   JPEG Support enabled
   libJPEG Version  8
   PNG Support  enabled
   libPNG Version   1.4.4
   WBMP Support enabled
   XBM Support  enabled

Enable pchart4mw to work both as tag extension and as parser function extension.

Working as parser function extension will enable integrating pchart4mw's 
charting capabilities with other extensions like Semantic MediaWiki (SMW).

The Chinese Character are not supported. The "textfont" parameter should only 
be a valid font file in the server. Thus, I recommend you to include at least 
one Chinese font in your package, to allow users use Chinese in you extension.

ALTERNATIVE SUGGESTION:

Another way is to use user-side fonts, but this may not be a good solution, 
because I know the charts are premade in the server-side.

pChart4mw uses the same fonts for the title and al the other text.

Create the possibility to choose (or set as default) a different font for the 
title and the other text.

What steps will reproduce the problem?
1. in mediawiki attempt to render the following chart:
<pBars size=600x300 title="PPS for Mod Types" labels=true angle="90">
"I=0Q=-5GI=0QO=-5SKEW=-500IQD=-500",4419.3333
"I=0Q=-5GI=0QO=-5SKEW=-500IQD=-500",4419.3333
</pBars>
2. profit?

What is the expected output? What do you see instead?
Expected result: Graph
Actual result: PHP execution time times out, apache uses 90% cpu during the 
timeout (90sec)

What version of the product are you using? On what operating system?
Linux:
Linux test 2.6.32-5-686 #1 SMP Mon Jan 16 16:04:25 UTC 2012 i686 GNU/Linux

Apache:
Server version: Apache/2.2.16 (Debian)
Server built:   Apr  1 2012 06:40:08

pChart:
pChart4mw v1.3.3.zip

PHP:
PHP 5.3.3-7+squeeze8 with Suhosin-Patch (cli) (built: Feb 10 2012 14:12:26) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Additional info:
This seems to be a problem with rendering the labels, specifically at any other 
angle then 0 and 45.  settings label=false or angle=45 is a workaround for this 
problem

What steps will reproduce the problem?
1.Use a high resolution screen, such as retina macbook 

What is the expected output? What do you see instead?
The graphs look blocky, and unprofessional. 

When I used a transcluded #xxx as the color, the render reads as invalid, and 
the color turned out black.

For example:
================Case 1===================
parameter is:

| colors = {{ColorSelector|Color1}}

in which, the {{ColorSelector|Color1}} gives <nowiki>#xxxxx</nowiki>

Since the template is a color selector, I add the <nowiki> around the color to 
avoid it break down when transcluded (If no "nowiki", sometimes the # will be 
parsed as lists).

>>> RESULT: turned black.

================Case 2====================
Another way I tried is: (parameter is the same as Case 1)
in which, the {{ColorSelector|Color1}} give &#35;xxxxxx.

I escape the # as &#35; to avoid wikitext broking.

>>> RESULT: turned black.

================Case 3====================
The third way is to use css-styled rgb color. Absolutly, this does not work.

****************** My Suggestions ******************
After I checked your code, I found in your wiki function that gets color, you 
just simply trim the leading # from color without any rendering.

As to this, the suggestion is to make some more steps in the wf that catch the 
color. Make sure it is parsed as plain text rather than wikitext first, and the 
use it as color value to assign.

Thank you.

Using parameter 'filled' without also using parameter 'cubic' in line charts 
does not work. For example:

<pLines ymin=0 filled plots legend>
,US,EU
Jan,6748,4301
Feb,3911,5019
Mar,3019,3941
Apr,4810,6412
May,2203,4823
Jun,4510,4110
Jul,3918,5510
Aug,8810,2930
Sep,7182,3504
Oct,6911,3881
Nov,6749,4761
Dec,7184,4918
</pLines>

In PHP files, ?> are not needed, hell, generally, not recommended to be used at 
the end of files. Only needed when input is broken for raw html etc

In MediaWiki this is even more the case, with it causing header and other 
errors with them at the end of the file

Please remove them

We have recently installed a wiki system to manage the documentation of a
large scientific code. My sysop told me that we could not use the asciimath
extension together with pchart4mw because your extension generates invalid
XML. The issue is partly due to the fact that asciimath relies on the
browser to parse the mathematics in MathML and then render the expression.
Invalid XML causes this parsing to fail.

Anyway, I traced this problem to pchart4mw generating HTML such as:
<img src="example.png" >
This is not valid XML as it has no end tag. The problem is easily fixed by
generating something like:
<img src="example.png" />
If you could add the additional "/" in the function htmlCode in
pChart4mw.class.php then you'll have one more happy user.

Best wishes,

    Huub van Dam ([email protected])

I'm have just been trying out the S5-based slide extension for mediawiki at 
http://meta.wikimedia.org/wiki/User:BR/S5_slide_for_mediawiki_documentation/en 
. Unfortunately it does not work with pchart4mw and the pchart "source code" 
appears in the slides instead of the generated graphics. In contrast, it works 
as it should for the graphviz extension, which does show graphs. This is 
confusing as both graphviz and pchart4mw appear to do the same thing, i.e. 
taking text descriptions and generates images. I tried to see if there was some 
callback function that p4chart4mw is missing, but I didn't see anything. Does 
anybody else have any idea of what might be missing? --Dov Grobgeld 07:33, 12 
July 2011 (UTC)

I found the reason for this bug today. It turns out that the hook associated 
with ParserFirstCallInit should use the parser object passed in as a variable 
instead of using $wgParser. The slidy extension uses a private instance of a 
fileparser object and not the $wgParser. Therefore the registering of the slidy 
object in $wgParser doesn't work. By using the $parser object which in any case 
is passed on to the ParserFirstCallInit hook you solve this problem. Dov 
Grobgeld 12:07, 15 July 2011 (UTC)

I have patched pChart to solve the problem above. My patched version is 
available at https://github.com/dov/pchart

I want to draw threshold line in my chart. Can I call this function 
(http://pchart.sourceforge.net/documentation.php?topic=pChart#) from extension?