Issue 76912

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:
Severity:	Trivial
Priority:	P3	CC:	issues
Version:	680m209
Target Milestone:	---
Hardware:	All
OS:	All
Issue Type:	ENHANCEMENT	Latest Confirmation in:	---
Developer Difficulty:	---

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.

Comment 6 Marcus 2017-05-20 11:11:40 UTC

Reset assigne to the default "issues@openoffice.apache.org".