Closed
Bug 12037
Opened 26 years ago
Closed 23 years ago
[PRINTING TRANS GIF] Transparent backgrounds are printed as black.
Categories
(Core :: Printing: Output, defect, P3)
Core
Printing: Output
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: chrispetersen, Assigned: dcone)
References
()
Details
(Keywords: relnote, topembed+, Whiteboard: [Hixie-P1], relnote-user, need to fix on Mac & Linux[adt2] for win32 fix)
Attachments
(3 files, 4 obsolete files)
11.14 KB,
patch
|
Details | Diff | Splinter Review | |
1.54 KB,
text/plain
|
Details | |
2.74 KB,
patch
|
dcone
:
review+
attinasi
:
superreview+
|
Details | Diff | Splinter Review |
Build: Apprunner
Version: 1999081608
Platform: All
Expected results: The directory that contains color icon should be printed as
greyscale.
What I got: The document icons are print as black/white on Windows. The Mac
prints no icons at all.
Steps to reproduce:
1) Type in the url:http://slip/projects/marvin/simple/
2) The directory should be displayed in the window. Notice that the document
icons of the files are in color.
3) Print the document.
4) Under Windows, The printout contains black/white icons instead of greyscale
icons. The mac version prints no icons on the page.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
QA Contact: petersen → shrir
Comment 1•25 years ago
|
||
Sorry for the spam, changing QA contact on printing bugs to our new printing
tester, Shrirang!
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12
Assignee | ||
Updated•25 years ago
|
Summary: Color document icons are printed as black/white or not at all. → [PRINTING]Color document icons are printed as black/white or not at all.
Assignee | ||
Comment 2•25 years ago
|
||
It seems that my test actually has inverted icons printed.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M15
Assignee | ||
Comment 4•25 years ago
|
||
This is because the transparent GIF's print differently on differnt printers.
*** This bug has been marked as a duplicate of 21380 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Summary: [PRINTING]Color document icons are printed as black/white or not at all. → [PRINTING TRANS GIF]Color document icons are printed as black/white or not at all.
Comment 6•25 years ago
|
||
Running in circles here. This needs to be re-opened and 21380 need to be
verified duplicate of this. I'm going with first reported inertia on this one.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Putting on PDT- radar for beta1. Will relnote for beta1.
Keywords: relnote
Whiteboard: [PDT-]
Comment 10•25 years ago
|
||
cc: sfraser
Comment 11•25 years ago
|
||
I checked in changes (to the trunk) so that transparent images print properly, on
Mac. The changes are in nsImageMac.cpp
Comment 12•25 years ago
|
||
*** Bug 23718 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15 → M16
Assignee | ||
Comment 13•25 years ago
|
||
This should be fixed. I put in a fix, and printing works much better. I had to
update printer drivers also for the Network printers, since tranparency does
depend on the Printer Drivers supporting this.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 14•25 years ago
|
||
I still see images print with a black background with build (2000042109). zach ?
Comment 15•25 years ago
|
||
Gif's printing in black also reported in bug 40821
url: http://www.ecst.csuchico.edu/~beej/guide/net/
Comment 16•25 years ago
|
||
reopening...per comment from R.K.Aa.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 17•25 years ago
|
||
*** Bug 40821 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Target Milestone: M16 → M17
Assignee | ||
Comment 18•25 years ago
|
||
This bug has been marked future because we have determined that it is not
critical for netscape 6.0. If you feel this is an error, or if it blocks your
work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M17 → Future
Comment 19•24 years ago
|
||
I should have fixed transparent GIFs on Mac to print with a white background
instead of random pixels. Shrir, can you test? I can't remember if there is
another bug on that.
Comment 20•24 years ago
|
||
yes, trans gif's are now printing with a white background on mac(2000091509m18).
Windows and linux are still printing as originally reported in this bug. Simon
do you want me to log a seperate one for mac ?
Comment 21•24 years ago
|
||
This is a glaring bug. On older sites where transparent images are used to for
spacing, the results look really bad. Any chance of getting a fix in for this
for NS6? I would be uncomfortable with this being the final release printing
performance.
Comment 23•24 years ago
|
||
Marking rtm-. Not enough time to solve this problem. Will have to look at this
post RTM.
Whiteboard: [PDT-] → [PDT-][rtm-]
Comment 24•24 years ago
|
||
It seems unclear to me whether this bug requires either of a "developer" or
"user" release note. If anyone feels it does, can they please draft one and then
nominate with the relnote-user or relnote-rtm strings in the Status Whiteboard.
Thanks :-)
Gerv
Comment 25•24 years ago
|
||
This bug is extremely critical to our products. Equations are usually created
as transparent GIFs for display in web pages. Putting a white background in the
equation is not an option, as we want to pick up any background color in the
user's document. Here is a page on our website that contains 2 transparent
GIFs, (albeit low-resolution):
http://www.mathtype.com/support/TSN/TSN50.stm
Please make this a high-priority item for the final release of Netscape 6.
Jack Dignan
Design Science, Inc.
Comment 26•24 years ago
|
||
keyword:relnote-RTM
Keywords: relnoteRTM
Whiteboard: [PDT-][rtm-] → [PDT-][rtm-], relnote-user
Comment 27•24 years ago
|
||
*** Bug 61659 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
reporters comment in bug 61659:
Note this graphic prints okay with the Non postscript driver
Comment 29•24 years ago
|
||
*** Bug 62795 has been marked as a duplicate of this bug. ***
Comment 30•24 years ago
|
||
*** Bug 63694 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
Comment 32•24 years ago
|
||
Adding myself to the CC list
Comment 33•24 years ago
|
||
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
Comment 34•24 years ago
|
||
*** Bug 68147 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
I dislike the 'Summery'. If I understand the newer comments correctly (and as I
have observed with my bug 68147) the problem is that the transparent background
is printed as black. The colours are ok and all images seem to print.
I therefore would suggest to change to summery. (And changing platform to all)
I think this is a must fix for mozilla1.0.
Since usually white is regarded as colour of the paper, it would be ok to print
the transparent parts as white (instead of not printing those pixels which is
probably better?).
Comment 36•24 years ago
|
||
Yea, the description is not accurate anymore, but I'm not so sure that this is
a bug on all platforms. I know that any platform using PostScript will have
this problem, but I didn't think that Windows and Mac had a problem with
transparent GIFs.
Can anywone confirm?
Comment 37•24 years ago
|
||
this is broken for me on linux using both postscript and the native
hp4 drivers on redhat 6.2. Asa's mac printed the background as white
(better than black, but suboptimal because the actual background was gray)
and his windows machine printed the background as black (but its set up
as postscript). I think OS should stay at "all".
updated the subject.
Summary: [PRINTING TRANS GIF]Color document icons are printed as black/white or not at all. → [PRINTING TRANS GIF] Transparent backgrounds are printed as black.
Comment 38•24 years ago
|
||
Before I had made a bad assumption that the postscript object was only used on
OS's that do not provide a direct printing context type of device. I see now
that this is not the case and have further confirmation from Dennis Lundberg
[dennis.lundberg@mdh.se] (who is having some problems with his bugzilla
account) that Windows 2000 on build 2001021508 exibits this bug when printing
to a PostScript printer driver, but not to a PCL printer driver.
Comment 39•24 years ago
|
||
This problem is not restricted to GIF images: I have this problem with printing
a document with transparent PNGs on our HP LaserJet (PostScript driver) but not
the HP DeskJet (which doesn't say it's PostScript, so I assume is PCL). Since
my diagrams are black lines on transparent ground, the result is large squares
of solid black...
Windows NT 4 SP6a, Mozilla 0.8 build 2001021508
Comment 40•24 years ago
|
||
transparent GIFs are still printing as black boxes on Mozilla 0.8.1
Windows NT4SP6
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9.1
Comment 41•24 years ago
|
||
*** Bug 80047 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 42•24 years ago
|
||
*** Bug 81782 has been marked as a duplicate of this bug. ***
Comment 43•24 years ago
|
||
Don, I think the problem is that for printing we need to invert the mask before
ANDING it with the destination. In addition we would need to OR the source
bitmap with the inverse of the destination.
The current sequence is:
1. Create a mask with 0xFFFFFF pixels mapping to the non-transparent pixels in
the source image and x000000 pixels mapping to transparent.
2. AND the mask with the destination.
3. OR the source image into the hole created by step 2.
The problem with this is that if the printer does not support the AND raster
operation then we are rendering the mask's transparent pixels as black pixels.
If we have it render the inverse of the mask then the transparent pixels will be
rendered as white pixels if the AND operation is NOT supported.
1. Invert the mask
2. AND the mask with the destination
3. OR the source image with the INVERTED destination. (I think the operation
DSTINVERT on WIN32 does this.)
Comment 44•24 years ago
|
||
Disregard my last comment. On WIN32, I think all we need to do is use
GetDeviceCaps(RC_NONE) to determine if the device supports raster operations. If
it doesn't support them then we should either:
Use the mask to composite the source image into an offscreen buffer then blit
the offscreen to the destination.
or
Copy the source image to the destination with any transparent pixels filled with
white.
Comment 45•24 years ago
|
||
10 dup bugs according to http://bugzilla.mozilla.org/duplicates.cgi. Marking
mostfreq.
Keywords: mostfreq
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
![]() |
||
Comment 46•24 years ago
|
||
*** Bug 86857 has been marked as a duplicate of this bug. ***
Comment 47•24 years ago
|
||
www.aol.com is chocked full of transparent GIFS, this printing
this page yields so many black GIFS..
we should get this fix in ASAP.
Comment 48•24 years ago
|
||
I too also have this problem. It seems to be something so fundamental to
printing that it should be fixed ASAP.
Platform: Moz 0.9.2, RedHat Linux 6.2
Comment 49•24 years ago
|
||
Just my 2cents from printer driver developer viewpoint:
As it was said before that depends whether printer supports generic ROP's or not.
For example PostScript printers do not have concept of drawing surface at all so
they cant combine output with already drawn content (only overpaint). Thus it
will never work on any PostScript printer.
PCL printers set required ROP with PCL Logical Operation (*l#O) command. The
problem is that this command is not defined in base PCL5 specification but only
in PCL5C (additions for color printing). It is supported not only with color
printers but with recent b/w printers, too.
These HP printers does not support this command: HP LaserJet III, IIID, IIISi,
IIIP, 4, 4M, 4Si, 4SiMx, 4L
Printers that correctly handle Logical Operation: HP LaserJet 4ML, 4P, 4MP, 4PJ,
4 Plus, 4M Plus, 4V, 4MV, all Hewlett-Packard color laser printers and ink
printers.
The problem is even larger with 8bit alpha blended PNG images. For blending
Mozilla wants to know what was already drawn (bitblt from device to memory
bitmap). Printer drivers do not support this kind of bitblt and return error (at
least Win32 and OS/2 drivers do this way).
I think that for printer output during page rendering all drawing primitives
must be sent to the printer DC (RenderingContext) AND some memory drawing
surface (kinda carbon copy). If there are transparent PNG images or printer does
not support ROP's then output is sent to printer in one pass as large bitmap.
BTW this one pass approach significantly reduces size of transfered image.
Comment 50•24 years ago
|
||
*** Bug 85628 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Whiteboard: [PDT-][rtm-], relnote-user → [Hixie-P1] [PDT-][rtm-], relnote-user
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 51•24 years ago
|
||
*** Bug 92495 has been marked as a duplicate of this bug. ***
Comment 52•24 years ago
|
||
*** Bug 93398 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
I just encountered this bug, found this entry and read the thread.
I'd just like to ask the poster who suggested that this'll never work
to PostScript printers: It works fine in Netscape 4.76. Can't the
developers emulate what is done in 4.76?
Assignee | ||
Comment 54•24 years ago
|
||
I am working on this bug currently,first on the windows platform. The
postscript platform might be more of a challenge because I am not sure if
postscript supports transparency. This problem 6.x is having.. we dont
composite our page.. so we rely on the device to support all the raster
operations. I am not sure what 4.x did, but I am guessing the composited there
output. If anyone knows what 4.x did, please post it in this bug.
Comment 55•24 years ago
|
||
The 4.x (or "Mozilla Classic") code is available in the tree, so you can go and
look for it.
Assignee | ||
Comment 56•24 years ago
|
||
I just did tests with W2k and my 4500 HP laserprinter, the transperancy works
just fine. This problem is bad because it is dependent on the
printer/driver/platform.. as to if it will work. Some platforms work, some
print an ugly black mask. One solution would have been to make the black mask
white so it would look better, but then that would break the systems that have a
printer that does support these raster operations. Another solution would be to
always composite this area when we print.. I think thats the only solution to
get this to work all the time.
Comment 57•24 years ago
|
||
dcone:
Is there a way to query the required info (e.g. whether (alpha) mask support is
present or not) from PPDs ?
Comment 58•24 years ago
|
||
Making the empty image bits white will look silly on pages with dark backgrounds
where its dark on white... I don't think this is a good solution.
Perhaps we should composite, however that kinda sucks too.
Assignee | ||
Comment 59•24 years ago
|
||
I checked with what explorer does, they do not support tranparency with there
printouts.. looks like they punted, but they do use white where the transparency
is. I think compositing will be really bad because of the resolution isssue..
size, etc. I think what should happen.. I will do the white background, but
will put in an option (at a later date) that will allow the user to do these
raster operations if the printer supports it. Also.. windows printers do not
tell if these raster operations are supported for the printer.. only if the
printer is a raster type so the user will have to make that decision. Seems
Netscape also does this white background thing.
Comment 60•24 years ago
|
||
Probably you misunderstood about that PostScript problem. I did not meant that
there are problems in nsPostScriptObj.cpp which manually generates stream in
PostScript language.
What I meant is that if you print from Windows (or OS/2 or Mac) on the
PostScript printer by using nsRenderingContextWin.cpp functions which map to the
GDI function calls then PostScript driver is unable to interpret the ROP3
SRC_AND for image mask and it tries it's best and replaces ROP with simple copy
(ROP3 = 0xCC = Source only). That's how these black areas appear.
I agree that replacing transparent areas with white color is BAD idea! Of
course you can do it as temporary solution. In that case you must provide that
printed page does not have background images or fill color.
Why you are against compositing page in memory? All necessary GFX functions
are there to do that. There are no any issues with resolution you mentioned. The
only problem is that it takes a lot of memory. For example A4 (aprox. 11 x 8
inches) page at 1200 DPI printer will take 11*8*1200*1200*3 = 380 Mb. This is
amount of memory Mozilla needs to print one page in worst situation (large
resoulution, entire page, truecolor). Printer driver compresses that chunk to
much smaller one and only then sends it to the printer.
Compositing is necessary only for documents that contain transparent or
alpha-blended images. You can't apply it to the separate page or even part of
page, because then problems with fonts could arise - printer device fonts could
look slightly different than system fonts.
The other bonuses of compositing are that it must be done only once in platform
independent layer. And most importantly it will work:
1. on all printers
2. with alpha-blended images. (I would love that feature)
It's just a question of time when it should be implemented.
Assignee | ||
Comment 61•24 years ago
|
||
yes all the GDI functions are there to do that, but that IS the resolution
problem. Creation of a large offscreen to support the resolution of the
printer your going to. So for a 300dpi.. not to bad, 4x, but for 600dpi or
2000dpi that is a huge offscreen.. which is a resolution problem. You could
band and you could.. and could... but these are pricy solutions.. we would
basically be writing our own printer drivers and just copy'ing the bitmap out.
Currently I think the solution would be to do what 4.x and IE do, use white.
The second phase would be to have the option in that the mask would be used like
it is currently for printers that support it. As the product stands now, the
raster operations work great on my 4500 laserwriter and 1 out of the two
Laserwriters at work, no bugs there. Leave those raster operations to the
printers that support it which should be more and more. Microsoft has a new GDI
transparent bitmap bitblit so I am sure more printers will have to support these
operations. I dont think us doing our own composition is ever a good idea
because its alot of memory and code to support a feature used maybee 5% of the
time.. if that.
Assignee | ||
Comment 62•24 years ago
|
||
Comment 63•24 years ago
|
||
r=peterl
Comment 64•24 years ago
|
||
sr=attinasi
Is it true that canRaster == DT_RASPRINTER only for some printers, and never for
a screen? Should Compostite be Composite, or something else?
Comment 66•24 years ago
|
||
Comment 67•24 years ago
|
||
Ignore my last update. I wished to post in another bug.
Assignee | ||
Comment 68•24 years ago
|
||
That is exactly how the documentation said to use this constant.. it will never
happen for a screen. I used the online documentation as well as programming
windows, Charles Petzold for reference.
OK, a=dbaron on behalf of drivers if you fix the spelling of Compostite to
whatever it should have been (Composite?).
Comment 70•24 years ago
|
||
*** Bug 96898 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 71•24 years ago
|
||
Windows fix checked into the trunk and 9.2 branch.
Assignee | ||
Comment 72•24 years ago
|
||
I checked in the windows fix for this.. so I am taking off the topembed tag.
This is just a Mac issue now.. and I will fix that next.
Keywords: topembed
OS: All → Mac System 9.x
Comment 73•24 years ago
|
||
Why remove the topembed tag? This is still an issue for the GTK embed. The
attached patch only fixes windows.
Comment 74•23 years ago
|
||
Set milestone to mozilla0.9.5 added nsbranch keyword
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 75•23 years ago
|
||
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 76•23 years ago
|
||
Also on Linux this is still not fixed...
I see a long vertical strip on the left side when printing
http://www.netscape.com
That strip is supposed to be a white trans image/gif(see the HTML) and
when you print that page using Win, you don't get a black
strip. So it is inly fixed on windows.
So that leads me to believe that this bug is not fixed
for linux.
Setting platform/OS to ALL.
OS: Mac System 9.x → All
Hardware: PC → All
Whiteboard: [Hixie-P1] [PDT-][rtm-], relnote-user → [Hixie-P1] [PDT-][rtm-], relnote-user, need to fix on Mac & Linux
Comment 77•23 years ago
|
||
I also just encountered this problem at www.asciitable.com trying to print the
ascii table on that page. It's a transparent GIF, and the background prints as
black. I right-clicked the image and went to "view image" and then tried to
print via file -> print.
OS: Mandrake Linux 8.0
Moz. Ver: 20011012
Printing to a Samba shared HP 812c
Driver: HP DeskJet 812C, Foomatic + DJ8xx (HP-developed driver)
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 78•23 years ago
|
||
Comment 79•23 years ago
|
||
Posted changes to nsViewManager::Display () to do compositing. This is just an
example how code could work in cross-platform way to fix black background
problem and printing of alpha blended images.
There should be some logic which determines whether page could be printed
directly to printer or it should be prepared in memory and then sent to printer
as one large bitmap. It should check whether there are transparent images in
document and what are user preferences for compositing if they are.
The other field for improvement to decrease memory usage is rendering the page in
limited resolution - 300 DPI should be enough. Then offscreen drawing surface
could be scaled to print on the entire page.
I made necessary changes (win32 and OS/2) to
nsIRenderingContext::CopyOffscreenBits () to accept both source and destination
as nsRect rectangles and thus support scaling.
The largest problem is to force nsViewManager::RenderViews to render page with
specified scaling factor. There is instrument to do that by adding scale factor
to transformation matrix in RenderingContext, but it is not always correctly
used. For example images and text dimensons do not scale right. The
nsFontMetrics read the scaling factor (twips to pixels) directly from
nsDeviceContext and thus ignores the scale factor which is specified in
nsRenderingContext.
I see at least two ways how to force rendering to be done at resolution which
differs from real device resolution:
1. Fix all places in nsRenderingContext to take into account the scaling factor.
Somehow change nsFontMetrics to use the scaling factor fromnsRenderingContext.
2. Make changes to nsDeviceContext to be able to specify desired resolution of
device. We will report smaller dimensions for caller for drawing surface. All
functions which get scale (AppUnitsToDevUnits etc.) will take this DPI
diffeerence into account, too.
I can try to implement this functionality. BTW this should automagically give
possibility to implement print preview!!!
I need to know which approach is better from your point of view. If someone in
Netscape / Mozilla is already working on or at least was pondering how to make
it I would like to hear back from them.
Comment 80•23 years ago
|
||
OK, can someone let drivers know what's going on with this bug?
I'm sick of paying for print cartridges. This bug is honestly costing me real
money.
No longer blocks: 104864
Comment 81•23 years ago
|
||
lol... Don't print 1024x768 gifs.
here...
http://www.engin.umd.umich.edu/~npietran/images/place.gif
1x1 transparent gif
Comment 82•23 years ago
|
||
*** Bug 108315 has been marked as a duplicate of this bug. ***
Comment 83•23 years ago
|
||
dcone is on sabatical. rod/kevin, can you take a look at this?
Comment 84•23 years ago
|
||
This is listed as a 0.9.6 bug so it would be nice to see a go/no-go on whether
this is even going to be possible. It might be a simple fix, it might not.
Assignee | ||
Comment 85•23 years ago
|
||
I am back from sabatical.
I dont think will are going to composite for a cross platform solution, this
would require to much memory since you would need an offscreen buffer 4 times
the size of the printer resolution at least. The fix for windows needs to be
implemented on Mac and Linux.. then this will be closed.
Comment 86•23 years ago
|
||
IMHO 24 Mb or 32 Mb (depending whether system uses 3 or 4 bytes per RGB pixel)
is NOT such a terrible amount of memory per Letter page (11x8 inches) in 300
DPI. The idea is not to use larger resolutions than 300 DPI even if the printer
reports that it can do 600 or 2000 DPI. Isn't the mAltDC (for print preview)
from nsDeviceContext.cpp the right instrument to do the rendering in any
resolution which we ask for?
Comment 87•23 years ago
|
||
this bug worries me a lot. i would like to use Gecko under Linux to automate
printing web pages for customers (don't ask me why...), so printing transparent
GIF backgrounds in white is not a solution, because most of the sites have
backgrounds images or colors. in this case Gecko is out for my project.
thus, Dainis Jonitis, i'm interested in your solution and i have a few questions :
does your patch compile with current Mozilla sources ?
do you know if it's compatible with printing Framesets and background images ?
i can mail Dainis privately if other bug contributors consider it's not
appropriate to have such a discussion on this report. anyway, i just wanted to
warn that printing backgrounds in white is not always a solution...
Assignee | ||
Comment 88•23 years ago
|
||
I agree that white backgrounds is a not an optimum solution, but it does take
care of most the cases. Using 32 meg.. to render offscreen is probably not a
big deal for some.. but there are alot of users who can not afford to use or
have that much extra memory. Also.. using a maxumum resolution of 300 dpi is
not practical with all the Inkjet printers.. or 600 dpi 1200 dpi and 2400 dpi
laser writers. I payed alot for my laserwriter, I would not like that 300 DPI
solution just so I could print out some.. if any transparencies. Also companies
like FedEx, UPS could no longer print there BarCodes at that resolution. They
use very large images which are sent to the printers to scale for them and give
them very high resolutions. Maybee a solution might be.. a preference to use an
offscreen.. warning of the DPI shortfall, this is only needed for
transparencies, or extreme memory that might be used.. something like that. But
I really have a problem doing our own printer rasterization just so a small
number of transparent things can be rendered. Its better to solve a problem for
95% cases.. than to solve for the 5% case. My point.. I believe there is a big
cost for doing offscreen rasterization.
Comment 89•23 years ago
|
||
I agree with dcone.
The best thing to do is to get a printer which supports alpha-masking or
transparency (via PostScript Level 3 or PCL5) ...
Comment 90•23 years ago
|
||
For many linux users, the important thing will be that ghostscript does it
correctly, because printing to inkjet printers relies on it.
I've tested the recent versions of ghostscript in Debian unstable, both
gs 6.51 and gs-aladding 6.50; for my test case (see bug 85628) both of them
still show problems with the transparent gifs.
I am not entirely sure about GS's behaviour: on the release documentation,
ghostscript is claimed to support level-3 features, but gs -h shows only
postscript level 1 and level 2. This might depend on how it is compiled.
The best option seems to be to have a configuratio option to chose between
'force to white workaround' and 'rely on postscript level 3 features'
Comment 91•23 years ago
|
||
I don't know if this is helpful, but when printing from acroread under linux
there is the option to use Level 1, Level 2, or Level 3 postscript. So, its not
completely without precedent to have such a work-around option.
Eric
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 92•23 years ago
|
||
FWIW, Konqueror prints these pages correctly. You might look at how they do it.
My test case is: http://www.engr.sjsu.edu/~knapp/HCIRODPR/PR_Mahal/M_metric.htm
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.2
Comment 93•23 years ago
|
||
Force-to-white print transparency has been checked in as part of bug 127430.
Comment 94•23 years ago
|
||
Marking topembed-. The issue has been resolved for WIN32. Remaining problem is
on Linux, Mac.
Updated•23 years ago
|
Keywords: mozilla1.0+
Comment 95•23 years ago
|
||
I'm still seeing this bug in Build 2002030403, Win2k. Is the patch not in the
standard nightlies yet?
Comment 96•23 years ago
|
||
*** Bug 130199 has been marked as a duplicate of this bug. ***
Comment 97•23 years ago
|
||
nominating for embedding and nsbeta. The comments suggest that this is fixed on
windows but it isn't. I'm still seeing large black areas for transparent gifs.
Print the image at
http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif and see for
yourself. This bug actually makes Mozilla/Netscape considerably more expensive
to use than the alternatives and will affect enterprise and home users where it
matters, in their pocketbooks.
Comment 98•23 years ago
|
||
WFM: When I print
http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif using
2002032203 build on WinXP on a HP LaserJet4. It prints the transparent area as
white, no black areas to be found.
Comment 99•23 years ago
|
||
032503 mozilla win32 build on win2K printing to LaserJet 4 prints black for the
transparet background for me.
Comment 100•23 years ago
|
||
Interesting... 3/25 cvs build on WinXP printing to LaserJet 4 prints white for
the transparent background for me. Must be a printer driver specific issue on
WIN32.
Comment 101•23 years ago
|
||
Running the 3/25 build on W2K:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020325
Netscape6/6.2.1+
When I print http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif,
I get black background on 2 printers:
HP LaserJet 5Si/5Si MX PS (lungfish on FLOTSAM)
Lexmark Optra T614 PS3(sanma on FLOTSAM)
Comment 102•23 years ago
|
||
HP 1200, last drivers, Win XP, moz 2002032003. All looks fine.
Comment 104•23 years ago
|
||
Using Win2k with Build 2002032603 printing on a HP5000N... Still printing all
transparent gifs with black background.
Comment 105•23 years ago
|
||
Works for me, build 2002031808 (a nightly--not a packaged version),
Debian/GNU/Linux, woody, CUPS version 1.1.14-3, HP DeskJet 842C. (Sorry for the
spam.)
Comment 106•23 years ago
|
||
On WIN32 we no longer go into the CompositeBitsInMemory routine which creates an
offscreen with a white background because the transparent gif is always
optimized. Instead, we fall through and call PrintDDB which leaves the user at
the mercy of their printer driver in regards to supporting the mask raster
operation needed to do transparency. This regression was probably caused by the
check in which removed the duplicate copy of the image bits by optimizing the
images. (bug 104999)
nsImageWin.cpp
------------------
if (!IsOptimized() || nsnull==mHBitmap){ <== The image is optimized so it
never goes to
CompositeBitsInMemory below
PRBool didComposite = PR_FALSE;
rop = SRCCOPY;
if (nsnull != mAlphaBits){
if (1==mAlphaDepth){
if(canRaster == DT_RASPRINTER){
MONOBITMAPINFO bmi(mAlphaWidth, mAlphaHeight);
CompositeBitsInMemory(TheHDC,aDX,aDY,
aDWidth,aDHeight,aSX,aSY,aSWidth,aSHeight,srcy,
mAlphaBits,&bmi,mImageBits,mBHead,mNumPaletteColors);
Comment 107•23 years ago
|
||
Attachment #46847 -
Attachment is obsolete: true
Comment 108•23 years ago
|
||
nsbeta1+ for WIN32 fix (Fixes recent regression which was preventing WIN32 from
printing transparent gifs correctly.)
Comment 110•23 years ago
|
||
Attachment #77142 -
Attachment is obsolete: true
Comment 111•23 years ago
|
||
Comment on attachment 77266 [details] [diff] [review]
Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage
sr=attinasi
Attachment #77266 -
Flags: superreview+
Assignee | ||
Comment 112•23 years ago
|
||
Comment on attachment 77266 [details] [diff] [review]
Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage
r=dcone
Attachment #77266 -
Flags: review+
Comment 113•23 years ago
|
||
adt: This patch is for WIN32 only. The symptom is that on a high percentage of
printers we will print black for transparent areas instead of white. top100
sites such as www.yahoo.com have transparent gif's which print with black
backgrounds on these printers. This regression was probably caused by the check
in which removed the duplicate copy of the image bits by optimizing the images.
(bug 104999). The patch is in WIN32 specific code, so it has only been tested on
WIN32. I have tested WINNT and WINXP printing several top100 sites.
Comment 114•23 years ago
|
||
adt1.0.0+ (on ADT's behalf) for checkin into 1.0.
Comment 115•23 years ago
|
||
Comment on attachment 77266 [details] [diff] [review]
Same as patch 77142 with additional code to cleanup the mImageBits after compositing offscreen to reduce memory usage
a=rjesup@wgate.com for drivers
Attachment #77266 -
Flags: approval+
Comment 116•23 years ago
|
||
Same as patch 77266 except I removed the assert that mImageBits is not null and
I destroy the mImageBits only if mImageBits was created during printing. (This
is a little safer since we should not be deleting mImageBits unless it was
created for the purpose of printing)
Attachment #77266 -
Attachment is obsolete: true
Assignee | ||
Comment 117•23 years ago
|
||
Comment on attachment 78072 [details] [diff] [review]
small change to patch 77266
r=dcone
Attachment #78072 -
Flags: review+
Comment 118•23 years ago
|
||
Comment on attachment 78072 [details] [diff] [review]
small change to patch 77266
sr=attinasi
Attachment #78072 -
Flags: superreview+
Comment 119•23 years ago
|
||
Fix for WIN32 checked in - attachment 78072 [details] [diff] [review]
Comment 120•23 years ago
|
||
Reassigning to dcone, marking nsbeta1-.
Updated•23 years ago
|
Attachment #47005 -
Attachment is obsolete: true
Updated•23 years ago
|
Comment 121•23 years ago
|
||
*** Bug 101618 has been marked as a duplicate of this bug. ***
Comment 122•23 years ago
|
||
verify bug 101618 when this bug is fixed.
Comment 123•23 years ago
|
||
> Fix for WIN32 checked in - attachment 78072 [details] [diff] [review]
Verified for me now:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020409
Netscape6/6.2.1+
Successfully printed:
http://www.mit.edu:8001/people/nocturne/athena/pics/rose.tran.gif
on 2 printers:
HP LaserJet 5Si/5Si MX PS (lungfish on FLOTSAM)
Lexmark Optra T614 PS3(sanma on FLOTSAM)
Comment 124•23 years ago
|
||
AS for comment #123 given url (rose) also prints correcctly under Linux
nighgtly build (2002040410) on HP 2100 (without the path i suppose:)
Assignee | ||
Comment 125•23 years ago
|
||
This is fixed for Windows. I will create new bugs for Mac and Linux concerning
this issue.
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → FIXED
Comment 127•23 years ago
|
||
sorry for the spam, forgot to mention here are the two new bugs
created for Mac and Linux if anyone wants to cc: themselves on those
bugs:
Mac = http://bugzilla.mozilla.org/show_bug.cgi?id=137114
Linux = http://bugzilla.mozilla.org/show_bug.cgi?id=137115
Updated•23 years ago
|
Comment 128•23 years ago
|
||
removing item for this bug from the release notes since the bug is marked
fixed. If this is in error, please make a note in the release notes bug for
the current milestone.
Comment 129•22 years ago
|
||
Transparent images are not printing correctly.
Can anyone please verify?
problem : transparent image covers background image.
On webpage http://www.mozillazine.org/poll_results.html?id=660
the background cloud and grass image (tile_gif.gif) does not show
through "mozillazine" (title.gif) or (blimp.gif).
On the www.microsoft.com page the transparent images
are not filled in with the correct background color.
mozilla build : 2003010304
OS : windows 2000
printer : lexmark optra m412
driver : pcl5 2.640, PostScript 30.740
Fails pcl5, ps, windows
Comment 130•22 years ago
|
||
rnorberg: Seeing similar things with 1.2.1 on Linux, printing to PS-File. Please
open a new bug report after looking for duplicates. This one is fixed. Thanks.
You need to log in
before you can comment on or make changes to this bug.
Description
•