Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Zoom minimum is at 5%|
|Product:||Impress||Reporter:||Armin Le Grand <Armin.Le.Grand>|
|Component:||editing||Assignee:||AOO issues mailing list <issues>|
|Status:||ACCEPTED ---||QA Contact:|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description Armin Le Grand 2007-05-03 16:28:11 UTC
AW: Due to #i4219# we will have page sizes bigger than 1,2x1,2 meters (the current maximum). Starting at ca. 3x3m the page can no longer be completely shown due to the fact that the minimum zoom we support is hard-wired to 5%. Here is an excerpt from #i4219# and explains which variables are involved and what needs to be done: AW: Zoom: As i thought, zoom is an integer value, so 1 would be the smallest, but 5 is used in SD (look for MIN_ZOOM, MAX_ZOOM and mnMinZoom). mnMinZoom maybe calculated by CalcMinZoom(), too (Impress?). Experimented in Window::SetZoomFactor(), the created MapMode for VCL works with 1/100th scaleX and ScaleY, too -> not hindered by VCL. To do it right, i would have to: - change mnMinZoom to double - change the MIN_ZOOM - change all usages and calculations involved mnMinZoom - change zoom display in status bar - change zoom dialog -> UI change - potentially change file format save/load (the zoom factor and last view position is saved and loaded) -> core change, API change, FileFormat change... AW->AF: I also experimented with 1 instead of 5 for MIN_ZOOM, works pretty well. But we will need the [0.0 .. 1.0] range for small zooms, too (at least in the future). Working range now [5 .. 3000] integer. Working range with integer-based DrawingLayer and VC MapMode (experimented) [0.1 .. 3000.0]. Future: Only UI limits when we are on double precision.
Comment 1 groucho266 2007-06-12 09:29:39 UTC
I it is not quite clear to me what has to be done for this enhancement: a UI change or just the extension of the zoom range, integer or float/double. Please explain.
Comment 2 Armin Le Grand 2007-06-12 10:19:21 UTC
AW->AF: This decision is up to the application. As i wrote, VCL today is capable of sub-integer values due to it's usage of fractions. To do it right and future-safe, i would recommend to use doubles and allow API input of values below and above one (e.g. 0.1%, etc...). This may be done even by a slider which maps it's linear range to e.g [0.01 ... 3000]%, but it's just an example. The current minimum of 5% minimum is too big today and 3000% will be too small tomorrow as soon as we will no longer have zoom restrictions due to the technical reasons of integer usage in DrawingLayer. HTH.
Comment 3 groucho266 2007-06-14 08:46:29 UTC
Techincally this should not be a problem. Removing the 5% lower bound clearly is not. The transition to rational or real numbers should also be relatively easy. Implicitly the zoom factor is already a rational number: the zoom factor is a percent value and represents the value <zoom factor>/100. Because it is ultimately stored as Fraction in a MapMode object, a rational number is a natural representation. Enlarging the denominator beyond 100 should solve the problem. However, if this change is done right, it will take some time. It needs a spec to be written and it would be a good chance to refactor and clean up the code (that is related to zooming). I therefore set the target to OOo 2.x.
Comment 4 groucho266 2007-09-17 09:22:17 UTC
This has to wait a little longer.
Comment 5 groucho266 2008-05-27 15:37:39 UTC
Retargeted to OOo 3.x due to time constraints.