The best we can do right now is not print XUL Docs. This patch checks to see if
it is a XUL document and if it is it idsplay a dialog and and doesn't Print or
Print Preview.
Bug 136185 r=dcone sr=attinasi
Font metrics returns both internal and external leading to layout. Layout
now is responsible for calculating the normalLineHeight. It take consideration
of external leading, and compensate if it does not exist. All these are controled
by a preference switch.
r=rbs, sr=attinasi,
clear some code points (mostly from 128 to 160) when generating raster
font cmap. Since most of the raster font does not contains those glyphs.
r=rbs, sr=attinasi, a=asa, adt
of it in now before the API freeze.
It adds several new attrs to the nsIWebBrowserPrint API and implments them in DocumentViewer.
It also adds a new platform specific interface for PrintSettings that will be
used when the "pluggable" dialog work gets checked in. Although these have been
tested via BUg 115136, these little nto no risk now because no one is using them yet.
Bug 132827 r=dcone sr=attinasi a=asa
of it in now before the API freeze.
It adds several new attrs to the nsIWebBrowserPrint API and implments them in DocumentViewer.
It also adds a new platform specific interface for PrintSettings that will be
used when the "pluggable" dialog work gets checked in. Although these have been
tested via BUg 115136, these little nto no risk now because no one is using them yet.
Bug 132827 r=dcone sr=attinasi a=asa
of it in now before the API freeze.
It adds several new attrs to the nsIWebBrowserPrint API and implments them in DocumentViewer.
It also adds a new platform specific interface for PrintSettings that will be
used when the "pluggable" dialog work gets checked in. Although these have been
tested via BUg 115136, these little nto no risk now because no one is using them yet.
Bug 132827 r=dcone sr=attinasi a=asa
because of the ordering of nsIWebProgressListeners. Even tho the doc WAS
finished loading the notification goes to mail first abd then it print and then
check to see if it is busy and it comes back that it is.
So instead I have to use two booleans to monitor if the document was asked to
be destroyed while it was preparing to print. This typically happens when the
user click on a click and it takes a while and then they decide to print. So
while the Print Dialog is up the document gets unloaded and when it returned
back everything is gone.
So when the flow of control returns back from the Print Dialog it checks to see
if it "should" have been destroyed, and if so, it then aborts printing, cleans
and displays a message if the pressed "OK". If they pressed cancel then it
doesn't print the message.
Bug 131174 r=dcone sr=attinasi a=asa
tor%cs.brown.edu
shanjian%netscape.com
pinkerton%netscape.com
dcone%netscape.com
hyatt%netscape.com
rods%netscape.com
bryner%netscape.com
rjesup%wgate.com
kmcclusk%netscape.com
mkaply%us.ibm.com
briane%qnx.com
caillon%returnzero.com
seawood%netscape.com
pavlov%netscape.com
ftang%netscape.com
sfraser%netscape.com
cbiesinger%web.de
dbaron%fas.harvard.edu
bzbarsky%mit.edu
bstell%ix.netcom.com