Added support for jpeg data uri in $canvas->image()#2783
Added support for jpeg data uri in $canvas->image()#2783bsweeney merged 1 commit intodompdf:masterfrom
Conversation
Other image formats already work with data uri's, but jpeg's don't as cpdf->addJpegFromFile uses file_exists. This change adds support for data uri's to addJpegFromFile.
|
Data URIs are handled by the Dompdf image caching logic, not the canvas library. The following seems to work fine: |
|
That works for images in HTML, but it doesn't work for embedded php or callbacks. For example, the following code doesn't work, but works fine with a png or bmp: The difference in behaviour between image formats suggests that this isn't intentional behaviour, and the wiki also implies that this should work. Maybe a better solution would be to update the CPDF adapter to use the same image caching as the HTML uses? |
|
Thanks for the additional info. I'll take another look at the change. |
You mean using a data-URI for a PNG or BMP adds the image to the PDF? That is entirely unintentional. I, honestly, had no idea that
Not sure I would go quite that far. The Cpdf backend will be extracted from Dompdf into a separate project at some point. |
| if(substr($img, 0, 5) == 'data:') { | ||
| $filename = 'data-'.hash('md4',$img); | ||
| } |
There was a problem hiding this comment.
Now wondering if we should apply this same logic elsewhere where the filename is used as a caching key since data-URIs can be quite large.
2 participants
Other image formats already work with data uri's, but jpeg's don't as cpdf->addJpegFromFile uses file_exists.
This change adds support for data uri's to addJpegFromFile.