![](https://forum.fusioncharts.com/uploads/set_resources_2/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
Álvaro González
Members-
Content count
25 -
Joined
-
Last visited
About Álvaro González
-
Rank
Forum Member
Contact Methods
-
Website URL
https://alvaro.es/
Profile Information
-
Gender
Male
-
Location
Spain
-
Internet Explorer converts UTF-8 data to single-byte
Álvaro González replied to Álvaro González's topic in Javascript Problems
Sorry if I wasn't clear. I found the issue right after upgrading to 3.6.0 (then downgraded to verify if the bug existed before, which was actually the case). And I'm not using Flash at all. I'll try to compose a self-contained test case. -
Álvaro González started following Google Chrome shows extra borders when printing, Internet Explorer converts UTF-8 data to single-byte, Add line feed to tooltips and and 1 other
-
Internet Explorer converts UTF-8 data to single-byte
Álvaro González posted a topic in Javascript Problems
In a fully UTF-8 enabled web site I use JavaScript to generate the JSON URL and pass it to FusionCharts: var title = "EVOLUCIÓN"; var url = "/foo.php?title=" + encodeURIComponent(title); var plot = new FusionCharts("/FusionCharts/MSLine.swf", "fc-" + this.id, "100%", "100%", debugMode); plot.setJSONUrl(url); plot.render(this.id); This works as expected in all browsers except Internet Explorer (I'm testing it on version 11). The developer console shows that the AJAX request to fetch the JSON data has already converted the double-byte URL-encoded data (%C3%B3) to an unencoded form (Ó) and some server-side debug code reveals it's not UTF-8 but some single-byte encoding (probably ISO-8859-1 or Windows-1252). I've just upgraded to 3.6.0 and I end up with "EVOLUCI?N" (earlier in 3.3.1 I'd get "EVOLUCIN"). Documentation says that FusionCharts requires a BOM in all UTF-8 source files but adding one didn't fix the problem. Is it a known issue? Do you have a workaround that doesn't break in other browsers? -
Thanks for your follow-up. With your code I can enable/disable HTML in the tooltip (verified with a <strong> tag) but <br> is always rendered as a line feed, no matter the value of isHTML. As I said, it feels like a bug but serves as workaround for my issue.
-
Yes, {br} works in ToolText but not in toolTipSepChar I'm afraid. Meanwhile, I've found a funny workaround: 'toolTipSepChar' => '<br>', It feels like a bug but it works anyway.
-
I'm using XT 3.3.1 to plot a Combination 3D (Simulated) Chart (Single Y) Specification Sheet chart (aka MSCombi3D.swf) with the JavaScript renderer. Default tooltips are not very readable for me because everything's in one line and I'd like to add a carriage return to separate the three items. I've learn I can use the toolTipSepChar property under charts: "chart": { "formatNumberScale": 0, "decimalSeparator": ",", "thousandSeparator": ".", "toolTipSepChar": "test", "showToolTipShadow": 1, "toolTipBgColor": "EEEEEE", "toolTipBorderColor": "EEEEEE", "caption": "Nº de intervenciones × mes{br}2012—2013", "labelDisplay": "Rotate", "slantLabels": "1" }, The property itself works but I cannot find a way to insert a line ending. I've tried both '{br}' and a literal "\n" but they didn't work: the first one prints a literal '{br}' (it's funny because it does work in caption) and the second one prints a white space. Is it possible to do what I want?
-
Please correct me if I'm wrong but I have the impression that my primary goal (setting graph dimensions for printing with pure CSS) is just no supported by the library. I guess that FusionCharts calculates and hard-codes pixel dimensions to ensure all elements (shapes, fonts, etc.) look great on screen. I don't think that can change in the short term. I don't really know why my Ugly JavaScript Hack doesn't work, though, and if you can find the time to shed some light on it I'll absolutely appreciate it.
-
I'm facing the issue in the following browsers (running on Windows 7 Ultimate 64 bits): Google Chrome 28.0.1500.72 m (32 bits) Mozilla Firefox 22.0 (32 bits) Internet Explorer 10 (64 bits) Opera 12.15 (64 bits) Do you mean that print preview in the fiddle shows both graphs with the same width for you?
-
I'm using FusionCharts/3.3.1 (more specifically, 3.3.1-sr2.19840)
-
I've created an online fiddle that illustrates the issue: http://jsbin.com/izutow/2
-
I was unable to find a CSS workaround so I've written a little JavaScript function to modify the generated <svg> and make it resizable: function handleDrawComplete(eventObject, argumentsObject){ var $svg = $("svg", eventObject.sender.ref); var w = argumentsObject.width; var h = argumentsObject.height; $svg .attr("viewBox", "0 0 " + w + " " + h) .attr("preserveAspectRatio", "xminymin meet") .attr("width", "100%") .attr("height", "100%") .css("width", "100%") .css("height", "100%"); } I use this function as handler for the DrawComplete complete event and, according to Chrome developer tools, graphs are modified successfully. However, graphs are still printed at fixed dimensions. The funny thing is that saving the page with the generated <svg> as static HTML works as expected! Is it possible that FusionCharts is triggering an event or something that manipulates the graph when user attempts to print? (I mean standard browser print, not managed printing.)
-
Google Chrome shows extra borders when printing
Álvaro González replied to Álvaro González's topic in Javascript Problems
Alright, I found where it comes from. This is what the bands look like: <rect x="66" y="84.20000000000002" width="432" height="52.19999999999999" r="0" rx="0" ry="0" fill="#eeeeee" stroke="#000" fill-opacity="0" stroke-width="0.000001" style=""></rect> For whatever reason, Google Chrome renders stroke-width="0.000001" as a thick line when printing. This workaround seems to do the trick: @media print{ rect[stroke-width="0.000001"]{ stroke-width: 0; } } -
I'm generating several plots with the JavaScript renderer, configured to fit in the available width. Relevant code looks like this: <div id="sales-plot">Loading...</div> #sales-plot{ width: 30%; height: 275px; } FusionCharts.setCurrentRenderer("javascript"); var salesPlot = null; $("#sales-plot").each(function(){ salesPlot = new FusionCharts("/js/FusionCharts/Pie2D.swf", "fc-" + this.id, "100%", "100%", debugMode); salesPlot.setJSONUrl("/data/sales-plot.json";); salesPlot.render(this.id); }); So far so good. Problem comes when the user prints the page: the plot takes twice the available width in a A4 sheet. I've tried tweaking my print CSS code but I've hit a wall—apparently, FusionCharts calculates and hard-codes the pixel dimensions of the graph: <svg height="275" version="1.1" width="379" xmlns="http://www.w3.org/2000/svg" style="overflow: hidden; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-user-select: none; cursor: default; position: relative; background-color: rgb(255, 255, 255);"> When I use CSS to reduce the width of the <svg> element or any of its ancestors I only get a cropped graph: @media print{ #sales-plot{ width: 5cm; height: 3cm; } } The graph keeps its original size thus it overflows the container. FusionChart resizes the graph when I resize the window, but obviously not when I print. Does this have an easy fix?
-
Google Chrome shows extra borders when printing
Álvaro González posted a topic in Javascript Problems
I've just switched to the JavaScript renderer because managed printing was taking several minutes to prepare charts on Google Chrome. To my surprise, graphs are printed exactly like in the screen in all browsers except Google Chrome. Here's a screenshot of a "MSCombiDY2D.swf" chart—on screen look on top, print preview on bottom: According to Chrome console that element is a <rect> tag and I haven't set a single CSS rule for such tags. Do you have any idea of where those black boxes come from? -
I've just fixed the issue by upgrading FusionCharts from 3.2.3 to 3.2.4...
-
I found the same issue, just to discover that it's also failing in regular browsers (e.g. Firefox on Windows) when you disable Flash. I suggest you make the same check: go to your desktop browser's plug-in manager, disable Flash and verify if charts still work.