I'm working on a printing template in the browser for print-to-pdf, and am using a transparent .png overlay in one section.
This happens both with transparent .png files and transparent .gif files:
Chrome, when printing (both to .pdf, and in the print preview window), seems to outline transparent images with a 1px gray line:
Exhibit A:
I've tried this in several other browsers (including Safari) and none appear to do what Chrome does. Has anyone seen this before? I need to find a way to disable it or hack it on the Chrome side so that this will work across browsers.
To see this in action, click here: http://jsfiddle.net/brandonscript/nELwd/ (just an <img /> tag) and press Cmd/Ctrl+P to bring up the print preview. You'll see this in the preview and if you print to .pdf. Make sure you have "Background colors and images" enabled, or you won't see any images.
Note: I'm not looking for workarounds after it's been printed and I'm aware that if you size the image to 100% and view the .pdf at 100% zoom you don't see the gray line. I need to programmatically (or otherwise) remove the gray line prior to printing the .pdf.
I have experimented enough and considered all the answers above while doing so.
Suspiciously, Upon saving your image and opening in gimp and some pokes into it, What I found was this.
Which makes me think that your image in truth, containing the gray border around it. My suggestion is you remove that layer and make that empty space around the actual image to transparent.
EDIT(response to #remus comment)
I do not know if my claim is correct, but I am believing that the image is not what you are expecting it to be. You need to correct that image. I have tested with another image of mine, pasted on the fiddle is not having any border around it in screen and print preview. (And the final pdf too). Sorry if this Answer is correct and hurts you.
Though I haven't come across this exact issue, I do a lot of work with css printing (for pdf and browser printing) and more often than not I have to use 2 images: 1 for screen and 1 for printing (do not use transparency for the printing one in yuour case):
<img src='http://apigee.ignite.ms/iloveapis/portal/badge/heart-overlay.gif' width='300' height='400' class="screen"/>
<img src='http://apigee.ignite.ms/iloveapis/portal/badge/heart-overlay_print.gif' width='300' height='400' class="forPrinting"/>
in your main css file:
img.forPrinting { display:none }
in your print css file which should be declared after your main css file:
img.screen {display:none }
img.forPrinting { display:block; }
Short Answer:
Change your PDF printing preset to a higher resolution.
you'll get:
The Long version:
I noticed you have re-sized the image by changing its width height properties in the HTML code.
So I made sure your image is exactly in the size you need it and it will not have this strange contour.
See Link: jsfiddle.net/cyVqw/
I have a print preview:
PDF screenshot:
To verify that in any size the PDF will keep your image transparency I checked
PDF saved in a Higher resolution preset i.e. "Print Quality". this resulted in a large file but with better zooming quality:
Here is High Resolution 33% preview:
High Resolution 200% preview
So, what you need to do is to adjust your PDF quality preset.
Related
I am using gimp designs to style my web pages. For some reason the dimensions are always off between chrome and gimp.
For example a div selected in gimp yields 200x450.
If I enter:
.some_div {
width: 200px;
height: 450px;
}
The div that shows up in chrome is always smaller.
Can I enable some feature in gimp to make the exact?
The number of pixels of an image in GIMP is exact. I simply can't be "off by 1" - the file save plug-in, for example, would crash, if it got informed the wrong image size.
Now...pixels as defined for CSS are not that exact - so, it possible the browser is off due to some settings or preferences (like ZOOM) - anyway, post a screenshot along with your question - maybe someone can get a better clue of what is oging on there.
Have you tried simply using another browser to check this issue?
Make a screenshot of your div in chrome and paste it into gimp, so you can get the exact size of it.
Google Chrome always seems to be changing the color of an image that I'm trying to match to a background color. I tried saving it in Photoshop and GIMP and even adjusted the color settings in each but it doesn't help in Chrome. FF and IE work fine (for once).
The color of my image is #282828. After I saved it as a PNG, I reopened it in both GIMP and Photoshop and used the eyedropper tool to confirm that the color was still #282828. When it renders in Chrome it's darker. I have a div with a background color of #282828, and the image is right next to it. I took a screen shot and the div's background color was #282828 and the images background color was #1d1d1d. I tried this for several different colors and each has had the same result. I even tried making the source image the color Chrome was rendering it as but Chrome still changes it. So for example, since Chrome was changing #282828 to #1d1d1d, I made the source image #1d1d1d, and when I rendered it in Chrome it was not #1d1d1d, but some other darker color.
At this point, I'm looking for either a fix or a programmatic work-around. Because the image is transparent, has curves, and a drop-shadow, there's really no way for me to avoid replacing the it, or even parts of it, with html.
Update:
I also tried saving it as a jpg and gif. gif actually works but can't preserve the drop shadow. The image I'm using is attached. If I take a screenshot of this in Chrome, GIMP's eyedropper tool says it's #1d1d1d. If I open the original and do the same, it's #282828.
PNG uses gamma correction to try to ensure that the image looks kinda the same across all monitors, and this can cause color mismatches like the one you're seeing. It's a combination of image editor issues and browser issues: image editors are not forced to embed gamma data inside images, and browsers are free to ignore the gamma correction if it's there and free to enforce some at random when it's not there. In this case, I'd rather think that Firefox ignores it.
Use a transparent PNG if you don't want its background to interfere with your page's background.
[EDIT] For your specific case, you may be able to replicate the graphics you're looking for by styling elements, using border-radius and box-shadow, two widely-implemented CSS3 properties that reasonably decay on older browsers.
I am on a team trying to convert our Flash Application into HTML5 and Css, and I am running into a bug affecting WebKit and wanted some help trying to figure it out. The basic idea is that there is a table with a single cell with a background image and a background color and for whatever reason when the image is exactly the right size background-size: 100% 100% the image actually shrinks to reveal the background color. This also repeats if I use pixel values instead of % values.
Before anyone tells me to just use a div (since its only one cell anyway), this content is authored by other people who are using an existing tool to create a custom xml document that gives us tables and I have to get my solution to work on the pre-existing content we already have.
This is the fiddle which shows it and follows are image in various browsers:
http://jsfiddle.net/CEvnx/2/
Flash (Reference)
Firefox (working)
Chrome (the image shrinks)
Safari (the image grows)
P.S. Ignore the height and font differences as those aren't in any way relevant to the problem.
has to do with the table's border-width, if you set border-width at 2px or less the background sizes correct (in Chrome/Safari). Quite strange that Chrome shrinks and Safari grows. There must be some odd math or image resize logic in webkit and probably worth submitting a bug report.
I have a div with the property:
background-color: #327EB2;
When I open the page on a browser I notice that a different color is shown. If I capture the screen and open the captured image on Photoshop, I can see that the color code captured is actually #437BB6. I have nothing set with that color in my CSS stylesheet.
I've tested on different monitors, different color resolutions, different browsers and versions from FF 4+ to IE8+, Opera, Chrome, Safari, etc...
Actually I don't think that's a problem of the monitor, resolution or browser version, because the problem is that the code of the shown color is actually a totally different one!
Also, Photoshop warns me about #327EB2 which is not a "Web Safe color", but I don't think this is the problem because I often use non-websafe colors in my sheets and I've never had an issue like that.
** Fiddle: http://jsfiddle.net/286tE/
*UPDATE
The problem is that the div has a background image and a background-color. The background color has to match the last pixel's color of the background image (as usual), which is #327EB2.
Anyway, I can see a different color from the last pixel of the image to the background-color:
http://test.testblueday.eu/test/cbsissue.png
You can see the page here, the problem is shown after the "Top Marchi" list on the left side:
http://test.testblueday.eu/test/cbstest.html
I've left the plain CSS and JS (not compressed) to let you see all the properties.
** UPDATE 2
I use Mac, but we can see the problem also on Windows.
You problem has nothing to do with the CSS, the problem is in the image!
This is because the examples supplied by you show the correct #327EB2 at the extra background (the one "coloured" via CSS), and that is enough to know that the CSS part is ok.
Beware of colour corrections/management done in the file exported via Photoshop.
If you can't colour manage/revert to the desired colour, another solution is doing the opposite, change the CSS colour to match the last row of the image.
As far as I can see, everything works correctly. Your image at the bottom has color with code '#1080b3' - I just downloaded that picture (gradient_box_emboss.jpg) and took a color with colorpicker in GIMP. When I modify css like this:
.embosser {
background: #1080B3 url('/images/gradient_box_emboss.jpg') right top no-repeat;
color: white;
padding: 5px 6px;
}
Difference is missing. When I printscreen your site and paste it into GIMP, color picker shows color of that "wrong" background is #327eb2. When I open your image you have in your question, color of background is #307db7. It is in jpg and I suppose some color information were lost while compressing raw data to .jpg. Possibly, something similar happens when you are trying to get color in photoshop.
Possibly problem rise when you convert images from one format to another. Simplest fix is above - change color of background to one you have on your image.
like
img { background-color:color: color matched to the theme}
or
img { background-image:url (a very very tiny gif image with the text "image loading") }
I'm thinking in the benefit of this when user access site on slow connection then background color will give clue about something is there which is diffrent than text content..
It's certainly a good approach. I would however try to assign as much as possible the same background color to the background as the strongest color of the actual background image. This way the website will still be representative whenever the client has disabled all images (as some bandwidth-limited users do or some handhelds by default do) or when its browser doesn't support images. The Web Developer Toolbar is helpful in this, in the Images menu you can choose to hide images so that you can see how it would look like without (background) images. I however wouldn't put a loading gif in. You can however consider to save the image interlaced (supported on GIF and PNG).
Sure, if you want to. In most browsers a space in which an image will load is already indicated, but there's nothing stopping you from doing a background color too if you like. I typically see this on body tags or other block-level tags that have background images, but I suppose you could do it on an image itself too.
In all honesty, I don't think this will actually make a site more usable than one that lacks this "feature."
An image-heavy site will probably look awful with a 'loading' background image, but if your site is not full of pictures, go ahead.
A small loading image is a nice touch, such as those from http://www.ajaxload.info/