I'm using highcharts-convert.js with phantomjs, and I'm having some text-overlapping issues when exporting the charts.
I believe the reason is Chrome on OSX renders fonts differently than my ubuntu server does. So when the client's browser builds the SVG the text does not overlap (I have indeed confirmed this by capturing the POST and rendering the svg in Chrome), but when phantomjs renders the text on ubuntu its slightly wider so there is overlap.
I believe that if I export the options JSON rather than SVG, ubuntu will lay out the text according to its own font rendering, and nothing will overlap.
Does that make sense? If so, how can I get highcharts to POST the options JSON rather than SVG?
I have this process that I can use to rig everything up, but it feels like there should be a better way...
var chart = graphContainer.find(".graph-body div").highcharts();
var chartOptions = chart.options;
delete chartOptions.chart["renderTo"]; // this creates a circular reference
// provide extra options to override the chart's defaults here...
$.extend(chartOptions.chart, {backgroundColor: "#FFFFFF", spacingLeft: 30, spacingRight: 30});
// wrap this up and POST it to the server...
console.log(JSON.stringify(chartOptions));
Related
I am just starting to use jsPDF and I think it may actually work (after attempting a zillion different ways to produce PDFs in my Quasar/Electron desktop application that have not worked).
Is there a way to display the PDF in the application window?
this.doc = new jsPDF({
orientation: "landscape",
unit: "in",
format: [4, 2]
})
this.doc.text(this.dogArray[0].dogCallName, 1, 1)
this.doc.save("test.pdf")
That works and I can save the PDF, but I'd also like to be able to display the generated PDF in the Electron browser window. I can console.log out this.doc, and I can display it on the window, but it's just a bunch of string info.
Is there something like doc.view("file.pdf") that can be used? I'm looking through the jsPDF documentation but I'm not seeing what I'm looking for.
I want to be able to see the PDF like the author shows on his Demo Website
I have read several posts on this subject but didn't want to piggy-back on any of them with additional questions.
Specifically this post: TCPDF and insert an image base64 encoded
I am generating a PDF from within a custom theme in Wordpress. I'm using TCPDF 6.2.3 (latest stable release, I believe).
I am building this PDF from the same HTML I am using to display on the page. If I embed the full base64 encoded string, it works correctly in the browser, but the image is missing from the PDF.
If I use the "#" method described in the linked post, I get a broken image in the browser (expectedly) but still nothing in the PDF.
All the rest of my HTML markup is rendering in the PDF, images are just not showing.
Is there some other setting or option I need to set in order to get the images to appear in the PDF, and/or can you spot anything I'm doing wrong here? No errors, the images are just not visible in the PDF.
This is how I set the image up:
$imageLocation = $img_root.$imgsrc;
$ext = end(explode(".", $imageLocation));
$image = base64_encode(file_get_contents($imageLocation));
//$response .= "<img src='data:image/$ext;base64,$image'>"; //works in browser but not in PDF
$response .= "<img src='#$image' class='socf_image'>"; //does not work in browser or PDF
And here is the method to create the PDF:
function createPDF($response)
{
// Include the main TCPDF library (search for installation path).
require_once('tcpdf_6_3_2/tcpdf/tcpdf.php');
// create new PDF document
$pdf = new TCPDF(PDF_PAGE_ORIENTATION, PDF_UNIT, PDF_PAGE_FORMAT, true, 'UTF-8', false);
// set document information
$pdf->SetCreator(PDF_CREATOR);
$pdf->SetAuthor('test');
$pdf->SetTitle('test');
$pdf->SetSubject('test');
$pdf->SetKeywords('test');
// set default header data
$pdf->SetHeaderData(PDF_HEADER_LOGO, PDF_HEADER_LOGO_WIDTH, PDF_HEADER_TITLE.' 001', PDF_HEADER_STRING, array(0,64,255), array(0,64,128));
$pdf->setFooterData(array(0,64,0), array(0,64,128));
// set header and footer fonts
$pdf->setHeaderFont(Array(PDF_FONT_NAME_MAIN, '', PDF_FONT_SIZE_MAIN));
$pdf->setFooterFont(Array(PDF_FONT_NAME_DATA, '', PDF_FONT_SIZE_DATA));
// set default monospaced font
$pdf->SetDefaultMonospacedFont(PDF_FONT_MONOSPACED);
// set margins
$pdf->SetMargins(PDF_MARGIN_LEFT, PDF_MARGIN_TOP, PDF_MARGIN_RIGHT);
$pdf->SetHeaderMargin(PDF_MARGIN_HEADER);
$pdf->SetFooterMargin(PDF_MARGIN_FOOTER);
// set auto page breaks
$pdf->SetAutoPageBreak(TRUE, PDF_MARGIN_BOTTOM);
// set image scale factor
$pdf->setImageScale(PDF_IMAGE_SCALE_RATIO);
// set default font subsetting mode
$pdf->setFontSubsetting(true);
// Set font
$pdf->SetFont('helvetica', '', 14, '', true);
// Add a page
$pdf->AddPage();
$html = $response;
$pdf->writeHTML($response, true, false, true, false, '');
return $pdf;
}
Well, fortunately, I was able to figure it out on my own. Perhaps this isn't the best forum for seeking help with this library? If anyone can suggest a better place to get help, I'd appreciate the direction.
Ultimately, the issue was two-fold:
The "#" notation is required for the PDf while the approach is what works for displaying the HTML in browser. So a string replace before creating the PDF solves that.
This is the tricky part. The HTML needs to use double-quotes around the properties, not single quotes. My code was using double quotes for the PHP strings, so the HTML properties were surrounded with single quotes and that was the issue. Swapping the two quote types was the last piece of the puzzle to get the images to appear in the PDF.
Hopefully this will help someone else who is pulling their hair out trying to blindly find their way through this library like me.
I have a page and there are four line charts on it. By having
exporting: {
enabled: false
}
I am able to see a Highcharts-generated export dropdown with options such as Download as PDF on each chart. These export options do not involve any access to the server. This is a pure client-side solution.
I wonder whether there is any way to use Javascript in the browser that allows me to export all charts on the page in a single PDF document?
Thanks and regards.
Well, I hate to be the one to break this to you but one clarification needs to be made, the default export options aren't really pure client-side. They leverage highcharts' own exporting server, one can override the exporting server's url using the exporting.url configuration option
url: String
The URL for the server module converting the SVG string to an image format.
By default this points to Highslide Software's free web service. Defaults to http://export.highcharts.com.
You may want to read their disclaimer & privacy statement & read more about the export module here
You can consider setting up your own exporting server, and override the export function to send SVG of all the charts on your page and do the stitching on the server side and send back the image.
exporting: {
buttons: {
contextButton: {
menuItems: [{
text: 'Export All Charts',
onclick: function() {
var allCharts=Highcharts.charts;
var svgArray=[];
for(var i=0;i<Highcharts.charts.length;i++){
svgArray[]=Highcharts.charts[i].getSVG();
}
// ... Post svgArray to your exporting server
}
}]
}
}
}
Having said that, modern browsers do support saving content of HTML5 canvas elements, check this jsFiddle that uses canvg library to export a single chart. P.S. This isn't the default behavior of highcharts
I am making firefox addon and I cann't manages styles to show correctly. For example, links color are always what page defines:
main.js:
pageMod.PageMod({
contentStyleFile: self.data.url("style.css"),
contentScriptFile: [self.data.url("jquery.js"), self.data.url("script.js")]
style.css:
#div_id {background:green}
#div_id a.black {color:black}
script.js:
$('body').append("<div id='div_id'><a class='black' href='#'>link</a></div>");
The result is: background:green is working, but #div_id a.black {color:black} is not working.
Page define a color and addon css-file can't change it. The only way to do it is $('#div_id a.black').css({'color':'black'})
What is wrong with addons css files? Why they are working only partially?
I will use this:
var styles = "#div_id {background:green}\
#div_id a.black {color:black}";
$("head").append("<style>"+styles+"</style>");
It is ugly, but it works.
I am using ABCPDF to print a PDF file to a local printer via EMF file. I've based this very closely on ABC PDF's sample "ABCPDFView" project. My application worked fine on my Windows 7 and Windows XP dev boxes, but when I moved to a Windows 2003 test box, simple embedded fonts (like Times New Roman 12) rendered completely wrong (wrong spot, and short and squat, almost like the DPI's were crazily wrong).
Note that I've hardcoded the DPI to 240 here b/c I'm using a weird mainframe print driver that forces 240x240. I can discount that driver as the culprit as, if I save the EMF file locally during print, it shows the same layout problems. If I render to PNG or TIFF files, this looks just fine on all my servers using this same code (put .png in place of .emf). Finally, if I use the ABCPDFView project to manually add in a random text box to my PDF, that text also renders wrong in the EMF file. (Side note, if I print the PDF using Acrobat, the text renders just fine)
Update: I left out a useful point for anyone else having this problem. I can work around the problem by setting RenderTextAsText to "0" (see code below). This forces ABCPDF to render the text as polygons and makes the problem go away. This isn't a great solution though, as it greatly increases the size of my EMF files, and those polygons don't render nearly as cleanly in my final print document.
Anyone have any thoughts on the causes of this weird font problem?
private void DoPrintPage(object sender, PrintPageEventArgs e)
{
using (Graphics g = e.Graphics)
{
//... omitted code to determine the rect, used straight from ABC PDF sample
mDoc.Rendering.DotsPerInch = 240 ;
mDoc.Rendering.ColorSpace = "RGB";
mDoc.Rendering.BitsPerChannel = 8;
mDoc.SetInfo(0, "RenderTextAsText", "0");//the magic is right here
byte[] theData = mDoc.Rendering.GetData(".emf");
using (MemoryStream theStream = new MemoryStream(theData))
{
using (Metafile theEMF = new Metafile(theStream))
{
g.DrawImage(theEMF, theRect);
}
}
//... omitted code to move to the next page
}
Try upgrading to the new version of abcpdf 8, it has its own rendering engine based on Gecko and so you can bypass issues like this when abcpdf is using the inbuilt server version of IE for rendering.
I was originally RDPing in with 1920x1080 resolution, by switching to 1024x768 res for RDP, the problem went away. My main program runs as a service, and starting this service from an RDP session w/ 1024x768 fixes it.
I have an email out w/ ABC PDF to see if they can explain this and offer a more elegant solution, but for now this works.
Please note that this is ABC PDF 7, I have no idea if this issue applies to other versions.
Update: ABC PDF support confirmed that its possible the service is caching the display resolution from the person that started the process. They confirmed that they've seen some other weird issues with Remote Desktop and encouraged me to use this 1024x768 workaround and/or start the service remotely.