While entering text the first time it seems fine. But as soon as the textfield loses focus the encoding seems to break and remains broken when entering the field again.
the following optlist was given to "add_table_cell"
fieldtype=textfield fieldname={price_5f215239aaa89} fitfield={multiline=true linewidth=1 font=1 fontsize=3 scrollable=false}
Edit
Pdflib version: 9.1.1
Font loaded with $pdflib->load_font($fontName, 'unicode', 'kerning=true embedding=true fontwarning=true');
The font is used by other elements in the Document without problems.
Font in Textflow
Font in Form Field
With PDFlib 9.1.1 you have to use a font with 8-bit encoding for a form field.
So you should load a second font with:
$fieldfont = $pdflib->load_font($fontName, 'winansi', 'simplefont embedding nosubsetting');
Please see PDFlib 9.1.1 API Reference, chapter 4.1, table 4.2 for details on the simplefont option.
Please apply the $fieldfont fonthandle to the form field option list.
Related
I'm trying now to convert a PDF file to JPG, using ImageMagick with PHP and CakePHP. The PDF is in perfect shape and it's right the way it should be, but the image generated from the PDF is always overflowing the borders of the file.
Until now, I've tried tweaking the code for the generation with no sucess, reading a lot from the PHP docs (http://php.net/manual/pt_BR/book.imagick.php).
Here are the convertion code:
$image = new Imagick();
$image->setResolution(300,300);
$image->setBackgroundColor('white');
$image->readImage($workfile);
$image->setGravity(Imagick::GRAVITY_CENTER);
$image->setOption('pdf:fit-to-page',true);
$image->setImageFormat('jpeg');
$image->setImageCompression(imagick::COMPRESSION_JPEG);
$image->setImageCompressionQuality(60);
$image->scaleImage(1200,1200, true);
$image->mergeImageLayers(Imagick::LAYERMETHOD_FLATTEN);
$image->setImageAlphaChannel(Imagick::ALPHACHANNEL_REMOVE);
$image->writeImage(WWW_ROOT . 'files' . DS . 'Snapshots' . DS . $filename);
Here are the results:
https://imgur.com/a/ISBmDMv
The first image is the PDF before the conversion and the second one, the image generated from the PDF where the right side text overflows.
So, why this is happening? And if someone got some alternative for any tech used (the GhostScript, ImageMagick, etc) is also welcome!
Thanks everyone!
Its very hard to say why you see the result you do, without seeing the original PDF file, rather than a picture of it.
The most likely explanation is that your original PDF file uses a font, but does not embed that font in the PDF. When Ghostscript comes to render it to an image it must then substitute 'something' in place of the missing font. If the metrics (eg spacing) of the substituted font do not match precisely the metrics of the missing font, then the rendered text will be misplaced/incorrectly sized. Of course since its not using the same font it also won't match the shapes of the characters either.
This can result in several different kinds of problems, but what you show is pretty typical of one such class of problem. Although you haven't mentioned it, I can also see several places in the document where text overwrites as well, which is another symptom of exactly the same problem.
If this is the case then the Ghostscript back channel transcript will have told you that it was unable to find a font and is substituting a named font for the missing one. I can't tell you if Imagemagick stores that anywhere, my guess would be it doesn't. However you can copy the command line from the ImagMagick profile.xml file and then use that to run Ghostscript yourself, and then you will be able to see if that's what is happening.
If this is what is happening then you must either;
Create your PDF file with the fonts embedded (this is good practice anyway)
Supply Ghostscript with a copy of the missing font as a substitute
Live with the text as it is
We have an Image processing microservice that created rich images with text on top of it and we are in the process of adding arabic locale to our website
While translating some of the content to Arabic our translator told us that the text in generated images not rendering correctly in arabic - they appear with no ligatures, so every character is separated.
We currently use ImageMagick (6.8.9-9) with PHP and the text generation used ImagickDraw->annotateImage that worked fine until we hit that ligatures problem.
I googled a little and found "pango" that solves that problem and also allows some sort of "html" syntax to define multiple settings for one text line which is pretty cool.
Problem is that I didn't find a way to use custom font files
This is the code:
$img = new \Imagick;
$img->newImage($width, $height, new ImagickPixel('transparent'));
$img->setBackgroundColor(new ImagickPixel('transparent'));
$img->setFont($fontFile); // didn't work
$img->setPointSize($fontSize);
$img->setOption("font", $fontFile); // didn't work
$img->newPseudoImage($width, $height, "pango:<span font='".$fontName."' foreground='".$textColor."'>".$text."</span>"); // font='".$fontName."' - also didn't work
I also tried to install the font in ubuntu OS and use only the font name but that didn't worked either, as well as combining all the options above or some of them.
I found that question:
PHP Imagick don't use custom font > convert does. But he said he used "caption" instead of pango - which doesn't provide that cool "html" syntax and does not solve the Arabic issue.
Please - if you know any solution I will love you forever!
Thanks.
I'm using tcpdf on generating pdf files out of html-snippets out of the prestashop (Version 1.6) source code.
Everything seems fine on viewing the pdf in Adobe Reader. On trying to send it via an electronic-fax service (e-post.de) i'm not abled to upload the file,...sadly without an error log or message.
On checking generated file on http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx, i'm getting this result:
Validating file "AYTKXFQRB_TestEins.pdf" for conformance level pdfa-3b
The required XMP property 'pdfaid:part' is missing.
The required XMP property 'pdfaid:conformance' is missing.
The embedded font program 'AAAAAB+ArialMT' cannot be read.
A device-specific color space (DeviceRGB) without an appropriate output intent is used.
The embedded font program 'AAAAAC+ArialMT,Bold' cannot be read.
The glyph for character 8364 in font 'AAAAAB+ArialMT' is missing.
The glyph for character 8364 in font 'AAAAAC+ArialMT,Bold' is missing.
The width for character 0 in font 'AAAAAB+ArialMT' does not match.
The width for character 0 in font 'AAAAAC+ArialMT,Bold' does not match.
The document does not conform to the requested standard.
The document contains device-specific color spaces.
The document contains fonts without embedded font programs or encoding information (CMAPs).
The document's meta data is either missing or inconsistent or corrupt.
Done.
I think, there are a lot of warnings which can be ignored. Files generated directly out of Adobe InDesign are also containing the majority of these warnings. The only warnings which seems to be hurting are these:
The required XMP property 'pdfaid:part' is missing.
The required XMP property 'pdfaid:conformance' is missing.
Any ideas how to resolve this issue?
EDIT:
Solution for the xmp-Error:
Setting the flag pdfa=true on calling the constructor to activate the pdfa_mode ...
public function __construct($orientation='P', $unit='mm', $format='A4', $unicode=true, $encoding='UTF-8', $diskcache=false, $pdfa=false)
But I have to still get rid of the font-errors :-(
I am having trouble getting a text field to auto size on a form I'm creating. I am setting the textSize of the properties to 0 in the properties of the TextField but it seems to just use the font set for the document. Here is the code I am using to create the TextField.
$pdf->TextField('description', 195, 32, array('multiline'=>true, 'lineWidth'=>0, 'borderStyle'=>'none', 'textSize'=>0), array('v'=>$description));
I know a kinda round-about way of possibly fixing this..
Before your textfield code, what ever you would like your font to be (not the default for the entire document) you could always try:
$pdf->SetFont('fontName','',fontSize);
And after your textfield code, just set the font back to what ever you wanted it to be for the rest of the document.
Not really sure if this was exactly what you were looking for, but I hope it helps. Good luck with it all.
I faced also that exact problem. I had a long time before I could find out the solution to this.
To make the field auto size the textual content, the font size of the field must be set to 0. It looks like TCPDF doesn’t support the javascript textSize option (see at the end of TCPDF_STATIC::getAnnotOptFromJSProp() ), so we must set the font size to 0 before the field, and set back again to its original value after the text field :
// Beware to use getFontSize*Pt* and not getFontSize.
// getFontSizePt gets the size in pt, and getFontSize gets the size in user units
// (units you gave when you created TCPDF object or default to mm)
// We need to set it again back with SetFontSize() which takes the font size in pt
$originalFontSize = $pdf->getFontSizePt();
$pdf->SetFontSize(0);
$pdf->TextField($name, $w, $h);
$pdf->SetFontSize($originalFontSize);
I'm using Excel5 in my project. I have already tried the following codes:
$objPHPExcel->getActiveSheet()->getStyle('A1')->getFill()->getStartColor()->getARGB();
and
$objPHPExcel->getActiveSheet()->getStyle('A1')->getFill()->getEndColor()->getARGB();
but these codes are returning wrong color. The getStartColor() always returning FFFFFFFF and FF000000 for getEndColor() instead of red.
I don't know what am missing. Can any one help me in figuring this out?
setReadDataOnly(TRUE) means read only the data from the cells, but none of the styling... and as background colours are part of the styling the reader will ignore background colours when it loads the file... if the fill style is not loaded, then the call to $objPHPExcel->getActiveSheet()->getStyle('A1')->getFill() will return default fill style and colours.
Load the file with setReadDataOnly(FALSE) and you should find it works
EDIT
This is way beyond the scope of PHPExcel.... everything is populated via DDE, including most of the styling, so the underlying fill colour is plain (as returned by the PHPExcel getFill colour call) until the external executable TOS.exe populates the data and sets the styles accordingly. Your only option here is to use COM so that the workbook is being executed in MS Excel itself.
Your second code:
$objPHPExcel->getActiveSheet()->getStyle('A1')->getFill()->getEndColor()->getARGB();
Works , it just returns a color hex code (FF0000).
RGB = Red Blue Green = xx xx xx
FF0000 is actually RED.