dompdf
Image does not render properly
it gives image with black background and the text on image of white color
I have questions:
- What is the nature of the text?
- Do you get any PHP errors?
- How are you loading your HTML document into Dompdf?
- How are you referencing your image from within Dompdf?
- If the image is "remote" (i.e. starts with http://...), have you enabled remote resource access?
Hey Brian,
- I am using normal html, which starts from
<html>tag and end on</html> - I didn't get any PHP error , it is successful but after rendering when I open pdf, then it has black and white image instead of colourful
- I tried both methods as via relative path of image and also with remote source, also I enabled remote resource access , But it will be helpful if you let me know How may I enable remote resource access within DOMPDF code
Thanks
On Mon, Jan 21, 2019 at 8:37 PM Brian Sweeney [email protected] wrote:
I have questions:
- What is the nature of the text?
- Do you get any PHP errors?
- How are you loading your HTML document into Dompdf?
- How are you referencing your image from within Dompdf?
- If the image is "remote" (i.e. starts with http://...), have you enabled remote resource access?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dompdf/dompdf/issues/1877#issuecomment-456104952, or mute the thread https://github.com/notifications/unsubscribe-auth/AsXtaQukhj0zbD67XlKWO5NZ1u0yV8cHks5vFdfJgaJpZM4Z3WZG .
So you see the image on the page but it's in black and white? Do you have a sample of the image and the rendered PDF?
Access to remote resources is enabled via the options. Call the following after you instantiate Dompdf:
$dompdf->set_option('isRemoteEnabled', true);
Its paypal icon original as :
huh ... looks like either the mask is being rendered by itself or the transparency isn't being set correctly on the mask. Are you using GD, IMagick, or GMagick? And which version?
That a screenshot of the image? Can you upload the actual image so I can test?
I uploaded both the images original as well as its rendered output in comment https://github.com/dompdf/dompdf/issues/1877#issuecomment-464590877
Please have a look , The coloured image is original image and the b/w image is rendered output I get , instead this I want the rendered images same as original coloured image.
Also I am not using any of IMagick, GMagick or GD version. Thanks Codeworld
The color image in your comment looks more like a screen shot than the actual image you're using (just based on the fuzziness and the transparency background). When I render it I get just what I see in the comment, not any kind of b/w image.
Also, that's a PNG, which requires some kind of image library (PHP typically provides GD by default). You can run phpinfo().
Having the same issue with php 7.4.8. When I downgrade to php 7.3.20 it works normally/as expected.
Example:
@robindirksen1 are these the actual images you're trying to render? Screen shots don't really help because I can't use them to reproduce the issue and right now I don't have any ideas on what's happening.
@bsweeney sorry, my fault.
- used file: Octocat
- Here is the screenshot of the recently generated file (php 7.4 mac): image
- screenshot of the generated file (php 7.3 mac):
Thanks for the follow up. When I render with that image on a linux box it looks OK. Are you using IMagick/Gmagick with your PHP install or just relying on GD?
Sorry, did you ever say what version of Dompdf you're using? And is that with ImageMagick 7? There was a transparency issue we had to address (595950cbcf67834beb82e5b4765e636f5e277d29) but that was fixed with 0.8.2.
Well, at least we have confirmation for IMagick 3.4.4. Do you know the ImageMagick version?
I still need to know which version of ImageMagick is being used behind the IMagick extension so I can troubleshoot further. I think as a fallback we'll make usage of Imagick/Gmagick configurable for a future release..
hi - I have problem of png images coming out negative
hey in lib/CPdf.php down around line 5689
// Since ImageMagick7 negate invert transparency as default
if (\Imagick::getVersion()['versionNumber'] < 1800) {
$alpha_channel->negateImage(true);
}
My version is 1802 - so negateImage is not being called
I'm using Alpine Linux with the channels set to latest-stable
- PHP 7.4.15
- php7-pecl-imagick-3.4.4-r7
- imagemagick-libs-7.0.10.57-r0
- imagemagick-7.0.10.57-r0
hi @bsweeney - looking for advice as to how this issue will pan out (I think it should get a bug label)
not looking to be too in depth here but .. wait for a solution or be active in working around?
the comment there Since ImageMagick7 negate invert transparency as default, infers that there has been a change at that version, but my distribution (Alpine) does not not seem to reflect that .. I've only recently converted to this from fedora - I had contemplated CentOS
So what do you think. Is it something that will/should change in DomPDF ?, or do you think No it won't, could there be a bug in the Alpine package?, I could consider moving to another distro … (I actually moved to Alpine to get heif support in ImageMagick, but CentOS has it too, Alpine just a little more edge, CentOS more conservative)
The other option is to go with GMagick, which avoids this line (DomPDF seems to prefer this)
If it's going to be changed, I would change the line in my vendor folder and wait for the change to come through
I think if we're going to support IMagick we should make sure the behavior is consistent across versions (as much as possible). So, yes, this will be addressed in a future release.
I didn't develop that logic, and I'm not familiar enough with the IMagick/ImageMagick code base to know what's going on here. I think the initial step I'd like to take would be to disable IMagick/Gmagick by default, and utilize an option to enable it. That way default installs will have consistent behavior across the board.
Then it's a matter of figuring out what's the appropriate method of determining feature support in the IMagick extension and ImageMagick version. Since querying the API doesn't seem to provide consistent results perhaps some type of feature testing is more appropriate. Worst case would be running a small (few pixel) sample file through IMagick and querying the result to see what the behavior is.
Hello,
We are having similar issues and were wondering if this is related to this bug. The issues we are having is not with inline PNG images but with PNG background-images. The transparant part gets filled out with black. The foreground hasn't changed though. We are using a different PHP and Imagick / ImageMagick version, which could explain the different behavior.
PHP: 7.3.33 Imagick: 3.6.0 ImageMagick: 6.9.12-54
Is there any solution to this? We also have GD on the server (version 2.1.0). If this is not related to this bug and I should be making a new issue, please let me know.
@9dninedegrees which version of Dompdf are you using? We addressed some version detection issues with more recent releases.