you should be able to zoom in and out of a page. I have known many times this would come in handy.

This is an enhancement.

The amount of reworking of the browser internals that this would require would be enormous! If we want Mozilla this side of the Millennium, I'm afraid you are going to be disappointed :-( There are options to change font size already. Are you having trouble reading small text? There's bugs on this, as well. Gerv

what is this resolved as? I'm not seeing anything in the Resolution field .is this jsut a moz bug :)

Actually, it is for pages that have a lot of text or pictures horizontally and vertically or big text and I would like to see more of the page. Or for looking at a really big picture. I would rather not download it and use paint shop pro or adobe photoshop.

Please reopen if you feel this would be good.

I can't resolve because I have had my ability to resolve removed.

Verifying unknown resolution to see what it is (I hope)

I have no idea what the resolution is (How weird) :) Anyway changing summary... If this was persued, Mozilla would be the first browser with ability to zoom.

Actually, I don't think it has a resolution at all. Bug within bugzilla?

Going to go on the newsgroup and see what people think about my new ideas. Do whatever you like with this bug.

boberb@rpi.edu: Mozilla wouldn't be the first browser with a zoom feature - Opera has it. Try it yourself, there's a free evaluation available at http://www.opera.com/ I'm reopening since I agree that this would be a great feature - even more so if Mozilla could resize images more smoothly than eg. Opera. (Yeah, I know it's extremely CPU-consuming to resample images on the fly. Maybe for Mozilla 3.0? :-)

asadotzler@netscape.net (Asa Dotzler) taking ownership of Browser General bugs. New QA Contact is jelwell@singleclick.com (Joseph Elwell). Sorry for the spam.

adding helpwanted keyword and reassigning to nobody@mozilla.org

Ie 5.5 have supported with Zoom. You can see big picture from zoom. It's new feature of IE 5.5. It would added this feature in Mozillia. feature Zoom would be suitable for image Gif, jpg and bmp.

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

In case you are confused, I meant a zoom like in word processors where you can scale the size of the document. It is still functional, just zoomed. I didn't mean, though, zooming individual images - I meant the whole page. All you have to do is multiply mouse clicks against 1/zoom_factor to see where they clicked and to display, you just send the full size document through a filter that resizs it. This would resize controls, text, and images.

That's exactly what Opera's zoom is doing. Very cool feature. (Changing Platform/OS to All/All, by the way.)

See also bug 46996: [RFE] XUL Lense

reporter - do you agree this is a dupe of an bug with the correct developers assigned to it?

No, I meant zooming like in Adobe Acrobat or Microsoft Word. Zooming within the whole window.

ie5.5 added print preview, a feature that netscape has had for years. Assuming mozilla had print preview (I think it does/will) and can zoom, would you be satisfied?

print preview is going to be in it, don't worry ;)

20943 is the print preview hook-up bug, currently nsbeta3-

> Assuming mozilla had print preview (I think it does/will) and can zoom, would > you be satisfied? No. It'd be like claiming that because Word has print preview, it doesn't need zoom in document editing mode. Print preview and "browsing zoom" are needed for two different purposes. Adding '4xp' keyword since Opera has had this feature for years.

Removing 4xp. That's an abuse. Please use status whiteboard instead.

From http://bugzilla.mozilla.org/describekeywords.cgi : "A bug is a Product Parity bug if it occurs on Mozilla builds, but does not occur using the latest release of Netscape Communicator 4.x or competitor products." I guess you refuse to count Opera as a competitor? :-) That being said, the definition can be interpreted so that _no_ competitor product may have the bug (or in this case, a missing feature) in order for the bug to qualify as 4xp. I understood that a bug is 4xp if there's one or more competitor product that doesn't have the bug - effectively giving "4xp" the meaning "somebody's ahead of us here!". Please tell me I was wrong, and I'll file a bug on Bugzilla requesting a more precise definition for the keyword.

Howdy timeless. Thank you for supporting this bug, Antti. I think taking a roundabout approach to zoom (ie - enlarging images/text) would not add as much to the functionality of Mozilla. I can tell you, if Microsoft Word, or Corel Wordperfect came without zoom - I would cry! Seriously, the enlarging text is a bad feature all in itself because it can really mess up some web pages' layout. I think Zoom would be a much better feature for someone with disabilities. I even think that if Zoom existed, you could remove the annoying enlarge text. BTW - Do you think people want someone going to a web page they worked hard on and enlarging my text? Even www.w3c.org talks about zooming in the CSS documentation. It said it wouldn't include zooming in the CSS definition - that is for user agents to do. I do not have any idea how this would be implemented - but someone must. It would probably require making a zoom class and going through the all interface code and multiplying dimensions by the zoom percentage. Does anyone have the guts/time to undertake this?

EXCERPT FROM CSS LEVEL 2: 18.5 Magnification The CSS working group considers that the magnification of a document or portions of a document should not be specified through style sheets. User agents may support such magnification in different ways (e.g., larger images, louder sounds, etc.) When magnifying a page, UAs should preserve the relationships between positioned elements. For example, a comic strip may be composed of images with overlaid text elements. When magnifying this page, a user agent should keep the text within the comic strip balloon. http://www.w3.org/TR/REC-CSS2/ui.html#q6

Bleh. It should be noted that the useragent should have some flexibility. If you make a 16x16pixel picture and force the useragent to render text in that, then it's your fault for constraining the text. The useragent should be helping the user experience the site. Zooming is actually a future feature, text sizing is a now feature (see mpt/jag comments on the sizing bugs). If someone wants to make a page that isn't obfuscatable by a useragent, they should use PDF, PostScript or JPG/PNG. Also that reference is useless, it says CSS2 will not govern sizing, nor future CSS. cc: hixie, mpt. fwiw, in a recent version of wordperfect, print preview is not readonly, it is just another view. Word might make a distinction.

So much talk, so little implementation ... To start with, this is a -->Layout issue. The layout engine, given a zoom level, needs to render the document such that: * text is rendered at the desired zoom level * objects (such as images) are rendered at the desired zoom level, but *only* if the zoom level is outside a certain (minimum,maximum) range which would be set in preferences (see <http://style.metrius.com/cssui/#docu> for explanation). Once that is done, two dependee bugs can be filed: one to add minimum and maximum prefs to the prefs dialog, and one to change the `View' > `Text Size' submenu to a `View' > `Zoom' submenu.

>> So much talk, so little implementation ... I agree Mathew. I'm glad someone is finally doing something with this. I would do it myself if I knew how / had the time.

Dividing up Claytons bugs to triage

marking future

This is a new message I posted in the Newsgroup: http://bugzilla.mozilla.org/show_bug.cgi?id=32646 I think there should be a zoom in Mozilla. This zoom should be similiar to that which you see on word processors, and adobe acrobat. It should zoom text and objects by exactly the same scale. There should be a min zoom of maybe 20% and a max zoom of maybe 500%. Any zoom within this range should be allowed by entering it in a special dialog box - selectable from the View->Zoom menu, or several predefined values on the menu can be selected. You can set an option in preferences to decide whether zoom values are kept when you go to a new page or not. I don't believe text or objects should be independently zoomed, because that affects the way the page looks - to the dismay of the page author. Therefore, I think zoom should be added, and the scale text be removed. I do not believe that there has to be a device independent unit of measure for zoom, as it is expected that someone with a very large, high res monitor should see more of the page than someone with a low res, small monitor. There is already a standard way to define text in terms of pixels. If it is zoomed out too much to read the text, then that is not a problem. I have heard that Opera and Internet Explorer both have a zoom feature.

This is how I believe zoom could be added to Mozilla. Firstly, you go through EVERY object, including buttons, text boxes, etc, and give them an ability to internally scale. You can do this without even disrupting any builds. You can then test it with the attribute zoompct - ie <textarea zoompct="50%">. This attribute would be removed when Mozilla was released. Then, one by one, you could test the zooming abilities of each object. Text boxes, etc could be zoomed by multiplying the width of the border * zoompct, the scrollbar width by zoompct (the scrollbar is another object), the scrollbar height * zoompct, and use the equation to convert pixels to points to convert zoompct to points, then multiply it times the text points inside the text box. You can then test each object's zooming ability alone. Then, you could use that same text zooming tecnique on the text in the document. Images are really easy to zoom. Most operating systems even have APIs to do it for you - or you could use a filter. After that, its time to put the tests into practice - you just multiply each object's top, bottom, left and right boundaries times zoompct before they are placed on the page, text would also be postitioned using the same technique, and viola! You have a zoomed document. You can even set lower and upper zoom limits based on what works and what doesn't. I think the zoom feature is really important. Disabled people should have the ability to view a document the same way we do without it becoming distorted by overflowing text. Its not always the designers fault someone can't see a document - besides being disabled, someone might have a really small monitor, or a very high resolution. When all designers move to CSS, overflowing text will probably be cut off. The text enlargement feature is no replacement for a zoom feature. It doesn't even zoom images. Text isn't always the only thing that needs to be enlarged.

I do not think this bug should depend on 37940, as that bug is about resizing text size - while this is zooming full content. Can we remove that as a dependency? The hope is that when actual zooming is added, text resizing will be obsolete and rarely needed. As there will be some page that a joker makes with 2pt font, text resizing will still be needed, but it has the ability to mangle people's pages - so hopefully people will use zoom more often instead.

reassigning to core layout

I see a fairly intensive implementation mentioned. Is it possible there's a simpler solution, such as at the GFX layer? (Plus maybe work with things that may bypass it, like GTK widgets/etc). If we could get some others involved (especially people who know "how it should be implemented" and can write it down), we can put some resources into implementation. This would be a big win for accessibility.

Marc Attinasi has some great ideas on how to proceed: 1) Make nsPresShell::GetScaledPixelsToTwips, GetPixelsToTwips, GetTwipsToPixels understand a zoom factor 2) Call nsPresShell::ReconstructFrames to reframe the entire document with the new zoom factor Images that don't have a width or height set will have to be dealt with. Look in nsImageFrame. We're not sure if the conversion routines for pixels to/from twips will handle all of the fonts or not. If the viewport width needs to be affected then there are some to deal with. I would hope this is not the case.

I have tested the solution proposed by Marc Attinasi and I think it's the right way to do handle the problem. There are still a lot of problems (images, fonts, size of scrollbars, size of the page...) but I will post some patches in about 2 weeks and ask for help/advise to finish the work

Cc'ing image buddies. /be

i also think this is a great idea, especially since it directly helps my own project ;). In the case where we need to create thumbnails of a page (for UI hacking, as in my case i'm creating a history UI which will use thumbnails) and don't want the top 16x16 pixels, but the entire page scaled.

*** Bug 72985 has been marked as a duplicate of this bug. ***

See also bug 73322, auto-resizing images to fit within the window.

Would someone please take this bug.

*** This bug has been marked as a duplicate of 4821 ***

vrfy dupe