Reassigned to Wolfram.

Reassigned to Falko.

Sorry, wrong owner. Now set to Falko.

Just checked v1.0.1... the 120x120 limitation still exists.

Any new thoughts on this call for enhancement?  I haven't tested 643
yet, does anyone know if this has been addressed?  644?

Is there something fundamental about the 120x120cm limits?

I just went to another conference and I had to (boo!!) use M$ products
because OOo couldn't make a 200x150 cm poster.

The limit is still there. OOo 1.1 Beta.

Increase maximum page size in Draw to 200x200cm 
(Note: We already support DIN A0)

started

Great news!

2mx2m will take care of my issues.  But, I'm just curious, why not
increase the limit to something bigger?  

Anyway, thanks again.

Hi, 

I posted this very question to the users mailing list, I got a reply
from Daniel Carrera:

"I can't find any option to do that, but I edited the source XML to
set the page size 
to 200cm x 200cm and it seems to work fine.  If you open the file and
go to Format > 
Page it shows up as "119cm", but when you view the file and work on it
you can 
clearly see 200cmx200cm worth of space.

I don't know how this will behave when you export it to some other
format, but if you 
want to give it a try, I've posted it here:

http://www.math.umd.edu/~dcarrera/openoffice/download.html

Let me know if it works.  I'm curious to know if there is any
fundamental reason for 
that 119cm limitation or not.  If there isn't, I would encourage you
to create an IZ 
issue for a "feature request" to increase this value somewhat."

This means it's possible to extend the maximum size manually. Is there
a reason for this limit of 119cm?

For academic posters this is a show-stopper, and judging from the
issue number this exists for a very long time.

If there is no reason, why not simply abandon the 119cm, to say: no
Limit or something very big > 2m at least?

b.

I can't see any reason for this limit.  Is this an arbitrary limit?
At the very least, it should be possible to set the limit under
Tools > Options > Draw.

What's the status of this issue?  There haven't been any comments since October.

Why is this set for "OOo Later"?  As far as I can tell OOo Draw is perfectly
capable of handling sizes bigger than 120cmx120cm (because I edited the XML and
it worked perfectly).

Is there a reason for this limitation?  It looks very arbitrary.  Especially
since OOo seems to handle larger sizes just fine.  Shouldn't this be a small
edit to the source code?  Just change the line that says "MAXIMUM_SIZE = 120" to
something bigger? (yes, I know that it doesn't really say that, but you get my
meaning).

Please explain why this is "OOo Later".

Hi,

As Daniel Carrera, I would be interested in the status of this issue. I would
especially like to know why this issue is around for such a long time (number
4219) and if there is a reason why it is set for OOo Later, does that mean >2.0? 
If that is so, then I would like to know why this is so difficult to implement,
when Daniel just changed a bit in the XML file.

As a student posters are very important. After writing papers and doing
presentations the most important reason for me to use an office application is
posters and the maximum-size of 120cm is a total show-stopper.

I am tired of using Powerpoint with it's half-baken drawing utilities but as
long as ooDraw cannot produce posters I am stuck with it, as are probably many
other students.

Pascal

*** Issue 25791 has been marked as a duplicate of this issue. ***

I just marked my issue as dublicate, but therefor I have to change this to
global problem, because I see no reason why  only drawings should be plotted
bigger than A0 ( think of large spreadsheets one of my users ask for)

I don't know if the printing dialog as to change additional?

And I see no reason to limit the papersize at all ( at least in one direction it
makes no sence if you have a plotter with a paper roll)

Hello,
a friend asked me to search for issues connected to setting the maximum size of
a page. He is interrested in using OOWriter or OODraw to create a scientific
poster for a presentation (the poster size would be 100*200 cm). 
The problem is, that the page width and/or height can not be increased over
119*119 cm. This has been stated by several other people in issue #4219.

My confusion is due to the fact, that I found several issues connected to this
problem, obviously unaware of the existance of the other issues. Here are the
numbers of issues that I came along in my search (there might be even more): 

#4129, #9982, #16260, #16293, #25791 

(my search strings were: "page width" and "page size")

What even confuses me more is the fact, that issue #16293 claims to have solved
this problem, but still people keep searching for the answer in the other
issues. (Or havn't even started yet.)
And, I don't know in which release this solution will be integrated, or whether
this "solution" really solves the stated problems in all other issues.

Maybe, this mail may help to sort and bundle the activities on the
"page-size-problem".

PS: I will post this mail to each of the issues stated above.

*** Issue 9982 has been marked as a duplicate of this issue. ***

*** Issue 16260 has been marked as a duplicate of this issue. ***

There exists another solution to this issue, which will remove the limits 
everywhere. Remember the old Mac OS days, when the printing dialog had a 'print 
at xxx% option"? Just add such an option to the print dialog, and you'll be able 
to make 12x12 meter posters by just setting the dial to 1000% (of course there's 
no reason to limit that scale factor other than constraining it to be positive).
I share the general stupefaction that this has proved too elusive for the 
maintainers to implement, esp. given all the other nifty things that have 
appeared since.

Until this feature is born, there exists another way out which will work fine 
for posters. Make it in the correct proportions, but at a size supported by OO. 
Then print it to a PDF file (a good idea anyway). Acrobat has a well-implemented 
option to scale the document to the selected printer paper size, so will take 
care of getting the right size for you. My last posters were printed like that, 
and it really works. If you stick to using only vector graphics and fonts, 
you'll see absolutely no difference. With bitmapped graphics (photos and the 
like), you can tweak the resolution of the picture you use (and you may wish to 
scale down an integer factor like 2 or 3).

well, I am happy to see things moving on. great.

Things would turn even better, if the priority of this remaining issue would be
increased, since obviously there have been quite a number of people looking for
help for a long time. And, the priority of the closed down issues was P3 and
even as high as P2 (issue 25792). So why leave this issue as low as P5 ?

Also, it would be a great advantage for OOo if it would provide this feature,
since especially people in the scientific field and at universities are a likely
group to leave MSoffice behind and to use OOo instead. But what to do, if you
can't produce a poster ? 
In the meantime I will certainly try the solution provided by rjvbertin (thanks
a lot for that).

Hi, 

The solution that  rjvbertin is a workaround that may well work for experienced
users. I for one haven't tried it, and would not know how to do that in Linux. 

In addition I can imagine that the rulers and sizes one uses to determine the
layout in the poster will be quite useless. 

I do not think this is a solution for everyone. And as this issue is (together
with the handling of effects in Impress) the major reason why Impress is not so
usable in a scientific context, I would also like this issue to have a higher
priority. But I will not interfere with the original poster - so please OOo
programmers: you rise it.

I don't know if this issue is included in the rework of the framework (issue
20477) but it seems a good time also to think about this issue when doing it.

Thank you

Created attachment 15185 [details]
Proposed patch to allow page size up to 1000 inches.

1000 inches ? 26 metres ? Is there an error ?

I think the limit should be 3 m x 3 m (too big ?).
ISO/DIN B 4B size is 2000 mm x 2828 mm.

Remind that on plotter, there is no limit for one side.

http://home.inter.net/eds/paper/papersize.html
http://developer.apple.com/documentation/Darwin/Reference/ManPages/html/gimpprin
t-mediasizes.7.html

lcn wrote:

> 1000 inches ? 26 metres ? Is there an error ?
> 
> I think the limit should be 3 m x 3 m (too big ?).

What??  Why would you artificially limit it to just 3m x 3m?
I don't see any reason to put such an artificial limit.  And at just 3m x 3m you
are still limiting the usefullness of Draw.  Even something as simple as a
banner often requires a lot more than 3m.  The "welcome banner" we used outside
the math building was 15m.  And it wasn't anything special.  It just said
"welcome incomming students".

I think that 26m is just enough to be useful for *most* banners.  But I have
certainly seen several banners much longer than that.

And banners isn't the only use for larger pages.  I once met a guy who needed
images that were several kilometers long and still had detail down to less than
a meter.  He worked for a gas company I think.  He needed diagrams of the
pipelines between cities.  These images are not large in terms of space.  They
have one very small dimension, and one very large dimension.  He was using GIMP
for it because it was the only application that allowed for that kind of image.

I think that, ideally, the sizes should just be float numbers.  But I realize
that this might be difficult to do.  So I say that we just add the current patch
to make the maximum size 26m.  That will suffice for most people.  And see how
we can improve that later.

Due to owner change the started flag got reset to new. Set to started again, as
FT has already evaluated this one.

I voted for this one some time ago, and the more I think about it the more I am
convinced that there is no reason for WP, spreadsheets, drawings, presentations
to have any limit at all.  

I'd like to see the possibility to specify a completely arbitrary page size, and
then offer the chance to scale it to any paper size when printing.  That would
seem to be something that no other product can offer (product differentiation is
a good thing) and remove all hinderances to operation.  If someone wrote a
postscript interpreter for a huge commercial plate-maker, why not be able to
print to it?

I agree to bobharvey. I also got stuck with the problem and I don't think that
if we would increase the limit, we would solve the problem. Only less users
would be confronted with this limit but there will still be some, that need even
huger pages, no matter how huge the limit is. Our computers do already limit the
size of the page because huge pages need a lot of memory, I guess. Why should we
set a limit that is below the limit of the resources of our computer? No matter
how fast your computer is, you want to use it completely and not just the half
of something stupid.

I agree to bobharvey. I also got stuck with the problem and I don't think that
if we would increase the limit, we would solve the problem. Only less users
would be confronted with this limit but there will still be some, that need even
huger pages, no matter how huge the limit is. Our computers do already limit the
size of the page because huge pages need a lot of memory, I guess. Why should we
set a limit that is below the limit of the resources of our computer? No matter
how fast your computer is, you want to use it completely and not just the half
or something stupid.

Adde myself to cc list

I think this would be a good time for feedback from a developer. We really need
more developer<->user communication. Right now we have little idea of whehter
this issue is easy to solve or not. And it doesn't help anyone to leave us guessing.

Cheers,
Daniel.

Daniel, is really easy: this issue has a one year old patch proposed by kediger,
so either the patch is good and the issue can be solved by integrating the patch
or the patch is wrong and it should me marked this way so another patch can be
proposed.

AW: Reason is that the DrawingLayer internally is (still) based on 32bit integer
coordinates and uses 1/100th mm. Together with the area surrounding the page
(where You can place objects, too) it's an area of 3x page size. So 2.2 billion
(signed integer) allows a theoretical max of 22 x 22 Km (21,47483648 exactly),
so the page may be up to 7,1 x 7,1 km big, theoretically.
BUT: There is a huge amount of integer-based calculations working on that, so
You need some security distance for numerical reasons. Those are not (at least
not all) numerically safe (!). There is no good argument for the current limit,
but one thing is clear: Each expansion of the limit will raise the possibilities
for numerical errors and nonsense happening in DrawingLayer due to numerical
errors (quadratic?). At least the current limit is tested by users.
Do not forget that You can also define a scaling in Tools/optins somewhere which
will also use some of the available internal precision. You will run in trouble
with huge values here.
So i would not recommend to change it for OOo2.0.
And Yes, we are working on changing the DrawingLayer to double precision
(hopefully for OOo 3.0). Since we cannot do a redesign (not enough manpower) we
are forced to slowly migrate, keeping the existing code working. So i cannot
guarantee for OOo3.0, but i see it as a necessity anyways.
HTH.

AW:  Thank you for the explanation. I wish more of the big issues would receive
clear explanations like this one.

Question: Hypothetically, what would be the chances of hitting a problem if the
limit was increased to 1 km x 1 km? or 100 m x 100 m?

I realize that no matter what you pick, someone, somewhere, will want it bigger.
But it makes sense to pick a number that is "pretty safe" and still is good
enough for "almost everyone". I can easily see people needing something bigger
than 2m x 2m (a large banner, an architectural drawing or a building). The only
man-made object I know of that is bigger than 1km are pipelines and electricity
grids.

So, we can accept that we won't support drawing pipelines until OOoLater but we
could support buildings and large banners in the near future.

In your opinion, what would be a reasonable size that is still "safe"?

Cheers,
Daniel.

I would also like to offer my thanks for the explanation, and the hints about
3.0 (My contributioon: turn it into a CAD system, lads!)

> The only man-made object I know of that is bigger than 1km 
> are pipelines and electricity grids.
The channel tunnel?
Certain australian freight trains?
I worked on a research ship that towed an acoustic array 1.5km wide & 8km long.
Hadrian's wall?

I would really like to see maybe a 6m x 6m page size.  My company owns 4 wide 
format printers, and we find it very useful to be able to print out giant 
spreadsheets, make large powerpoint slides as posters, print banners from Word 
etc... The current limit makes OpenOffice not viable for us.  We have priters 
at 36" wide and 60" wide, both with unlimited length printing.  We usually 
don't print longer than 200", but wouldn't mind a higher limit for those rare 
occasions.  Most Kinkos locations have large format printers available for the 
average person to go well over the current limit.

Regarding the limitation and usefullness - One of my colleague wanted to have
5meter x 6meter page size - Draw perfectly fit him do his business except the
page size limit. 

Regarding the limitation and usefullness - One of my colleague wanted to have
5meter x 6meter page size - Draw perfectly fit him do his business except the
page size limit. 

I would just like to give support to developers solving this issue and I can say
that I meet many people affected by it, especially in academic community for
making poster presentations (important part of the work), and less in
engineering community as they generally use more CAD programs.
Also, I think the priority should be more than P5 as this is A BIG issue for
people in science trying to switch from proprietary software to OO. All other
issues are pretty much sorted (writting, drawing, presentations, spreadsheet),
but this, which keeps acceptance of OO back, at least in our research institution.

Igor

*** Issue 64490 has been marked as a duplicate of this issue. ***

to BH:
Please consider to assign this issue to somebody. maybe FT ?  
since it already have proposed patch, rfe_eval_ok, and already more than 4 
years old. 

If the proposed patch did not work, please comments. but if the proposed patch 
is working, why not accept it ?

Thanks

Hello Kai, this RFE has now been changed to patch. You know, that all issues
with the pre-approval keyword rfe_eval_ok are waiting for their final approval.
Thus this issue is also on the list. Could you or Christian please check this patch?

an issue with 49 votes can not be P5, from my point of view. Now it is P4.

accepted patch for OOo 2.x, although we need to define the detailed size more
precisely, maybe based on suggestions from voters of this issue.

Well, I'd re-state my views of November 2004.  Autocad appares to have no limit
to what you can draw, I recall a ship navigation system where you could zoom out
past alpha centauri, and the only limit that makes sense to me is what the user
wants.  If he has 4Gb of ram and is still prepared to wait while something 100
times bigger is swapped in and out, so what?

I'd certainly suggest that the largest commercially available paper should be
catered for, and the remarks about printing a banner suggested that suzes up to
hudreds of metres may be required by somebody, somewhere.

So, like I said last time.  Arbitary drawing size, and the ability to scale to
arbitary paper size.

Armin, could you again think about the code currently used and give a rough
estimation of a size that is not going to break everything at the first look.
Personally, I can live with some 'insecure' values.  Arbitrary sizes would be
nice, but are not possible with the current implementation. So, please adjust
the patch according to your experience with the algorithms currently used. I set
the target to 2.3 to give us the chance to change this value for the next major
release (2.4), in case something fails.

AW: I can try.
AW: One definite statement from theoretic informatic: Each enlargement will
raise error probability quadratically.
Let's see: We have signed 32bit integer, one bit for sign, 31bit for value ->
2^31 -> 2147483648.
We use 1/100th mm internally in DrawingLayer, togehter with the 3x surrounding
page area and a maximum of 120 x 120 cm, for now 120 * 10 * 100 -> +/-120000 are
used as values. You need 17 bit to display this (2^17 -> 131072).
So we have 31 - 17 -> 14bit calculation space left.
This means if there is a calculation step involved which exceeds a multiple of
2^14 (16384), the result will be wrong (!)
Think about scalings where You first multiply and then divide using integers or
similar stuff...

Now let's talk about suggested values:
Doubling from 120x120 to 240x240 reduces the reserve by 1 bit and thus doubles
the risk of error.
Quadrupeling from 120x120 to 480x480 quadrupels the risk.

So, when using e.g. 1000x1000 cm instead (and seeing it as 1024 for simplicity)
we will need 1000 * 10 * 100 -> 1000000 -> 2^20 (1048576) bits instead of 2^14,
so the risk would raise by the factor 2^6 (64).

If You ask me, i see two possibilities:
(a) Do nothing until we are on double precision arithmetics in 3.0
(b) Remove all bounds and welcome a whole bunch of errors

I see no sense in choosing a 'bigger but not too dangerous' bound. Changes will
lead to errors, it will just differ in the amount when someone uses that feature.
ATM we protect the user in some way, but also not safe and sufficient. So i want
to hear Your commments.
Keep the limit or remove it completely?

AW: OOps, i forgot the 3x page area which again costs ca. 1.5 bits. Since i
forgot it everywhere, the relative value of 64 is still valid, though for the
1x1 m example.

AW: What's going on? We have 11 people on CC for this issue and 49 votes. Please
give Your comments after reading the last part thoroughly and having understood
the risks involved.
I need Your input here. I will not decide myself and take all the potential
upcoming bugs on my shoulders...

We just got a user's request on the German dev mailing list, asking for higher
limits in order to be able to print some technical drawings on a plotter using
OOo: http://de.openoffice.org/servlets/ReadMsg?list=dev&msgNo=31257

Let us see what the user tells: MS Excel can't cope with a graphic of more than
3 m, but Calc can do. (It might be very interesting for the user experience team
to see that somebody uses the spreadsheet module for printing graphics. ;-)
Unfortunately, when printing the graphic, it will be cut every 119 cm, because
this is the maximum page size in both, Calc and Draw. The user can't understand
why an advantage in competition with MSO suddenly turns into a disadvantage.

So I think we can learn that the current size limit obstacles our (potential)
users, and that they don't understand why there is this limit. On the other
hand, if we allowed even unsafe values which lead to errors, it would damage our
reputation. But I don't think an "either anything or nothing" position is
helping here, unless we can guarantee a date for an implementation that is both,
safe and suitable for our users. As we neither know when OOo3 will come, nor if
the precision problems will be solved until then, I think this is the moment for
a trade-off, in particular because the possible errors will only occur with very
large (> A0) paper sizes (or am I wrong on this?).

The user says he is using paper rolls of 50 m length. I think this should be a
pretty sensible limit for the length. For the width he is asking for more than 3
m, possibly 5 m, which for me seems sensible, too. Thus, I'ld like to suggest to
increase the page size limit to 5 m x 50 m. If both values need to be the same,
5 m x 5 m would be acceptable. (How much of our "margin of safety" would this cost?)

My vote for having this implemented ASAP. Not only in order not to miss the
OOo2.3.0 deadline, but to have more time for testing, too. (Maybe this is also
something somebody wants to tell about in the developers' blog?)

AW: Thanks for the reply, the only one so far. Here comes the math:

(a) 120 cm -> 120 * 10 * 100 * 3 -> +/-360000 -> 2^19 (524288)
(b) 500 cm -> 500 * 10 * 100 * 3 -> +/-1500000 -> 2^21 (2097152)
(c) 5000 cm -> 5000 * 10 * 100 * 3 -> +/-15000000 -> 2^24 (16777216)

2 bit more for (b), 5 bit more for (c) ->
at least 4 times the risk for (b)
at least 32 times the risk for (c)

Just one reply? Thanks go to mbayer. Thanks for Your comments.

To the others: Please give more comments.
How urgent is this when we get one reply until now? 
Remember: We have 11 people on CC for this issue and 49 votes.

well, maybe i'm the only one, but... i must admit that i did not understand the problem :)

re-reading all this a couple of times makes me think i almost understand it and can try to describe 
it as a user (that i am) would see it.

looking at values as decimal, not bitwise, they have some reserve precision.
increasing allowed values leaves less room for precision reserve, so repeated actions have larger 
chance that results slightly deviate because of the lost precision.

is this at least approximately correct or am i talking complete crap here ? :)

AW->richlv: Thanks for Your comments. Well, Yes, it goes in the right direction
(so, no, no crap at all :-). Unfortunately, it's not about 'slightly deviate'
but 'completely wrong' when calculations exceed the displayable limit.

Let's make a decimal example.

When You add any 2 single-digit numbers, the result may at maximum need two
digits (9 + 9 -> 18). When You have three slots to remember the result, You may
add up to (999 / 9) -> 111 single-digit numbers without danger. If You add more,
Your result may be wrong (overrun), depending on the added numbers (not all need
to be 9, but maybe).

When multiplying, it gets worse. Potentially in binary space, You need double
the space to be on the safe side.

What happens often is something like scaling all values of e.g. a polygon. With
integer numbers, the factor is normally a fraction, e.g. x / y. Multiplying with
this fraction is:

a = a * x / y

Now an example with numbers, a = 250, x = 10, y = 3 (multiply with 3.333...).
Expected integer-result is 833.

But that's not what You get with limit to 3 digits:

a * x -> 250 * 10 -> 2500, three digits -> truncated to 500
500 / 3 -> 166

The in-between result does not fit in the choosen number space. Dividing before
multiplying looks like a good idea, but will make the result more unprecise:

250 / 3 -> 83, * 10 -> 830, three off from the expected result.

For addition this means: errors with less numbers involved (e.g. center of
polygon, all points get added and divided by count -> errors will happen with
polygons which work today)

For multiplication this means: The chance to get completely wrong results
increases by the given factors.

HTH. Comments?

thanks for this explanation, now it is much more clear to me :)

1. what are the thoughts on reducing surrounding area ? this would give more space for actual 
content. of course, it might be critical for some cases...

2. i know that options are hated by many, but maybe make limits optional, but only changable in 
config files directly.

this way, users can create documents with any size, but forcing them to jump through finding out 
_how_ and making them edit files should allow to inform them about implications (though some 
very braindead explanation would have to be written :) ) and clearly communicate the point that this 
is possible, but can bork things.

this would be  an intermediate solution until proper solution is ready.
are there any at least vague estimates on oo.org version/timeframe when large page sizes could 
be possible without or with small enough risk ?
what would be the maximal size with the planned doubled precision ?

mbayer -> aw: I recently complained about developers not commenting issues well,
in particular older, but high-scored (votes) issues. Sad to see that sometimes
developers that do their best wait for users' feedback in vain.

Maybe it would be helping if you explained one thing: If we increased the
maximum page size to, say, 5 m x 5 m, would the risk of wrong calculations only
affect pages of > 119 cm, or pages of any size?

Does increasing the maximum page size jeopardize operations that we currently
consider safe? Or does it just add a - though not reliable - plus?

AW: Some more feedback (thanks for that) , Some more answers :-)

First, to richlv:

To 1: No good optin for me. Many people use the space outside the page when
temporarily rearranging objects and stuff. It will also not bring a too big win:
Instead of limiting to 1,20m and having the area, we would limit to 3,60m and
have no area outside the page.

To 2: This may indeed be a good option. If the people involved so far would
accept that solution, we would just have config entries for the now in place
1.20m. Good suggestion!

"are there any at least vague estimates on oo.org version/timeframe when large
page sizes could be possible without or with small enough risk ?"

Well, we constantly move forward and all stuff we touch or recreate is capable
of better precision. It's still hard to estimate, the whole model is untouched
ATM and so are other parts. We hope to have those enchancements for 3.0, but
it's only a guess. Problem is manpower here.

"what would be the maximal size with the planned doubled precision ?"

Of course IEEE numbers also have technical limits, but they are more 'flexible'
with numeric ranges than integers. When working on a bigger scale, the
associated minimums get more unprecise and vice versa. Think about it this way:
When using 5km and working on it, maybe details on 1/100th mm will be a little
more rough.
To make more precise statements i would have to go more deeply into the numbers,
but with IEEE numbers i would just take the restriction to some km and also
remove the maximum zoom bound of nowadays 3000% (guess the reason for that...)

Now, mbayer:

"Maybe it would be helping if you explained one thing: If we increased the
maximum page size to, say, 5 m x 5 m, would the risk of wrong calculations only
affect pages of > 119 cm, or pages of any size?"

Only the new, bigger ones.

"Does increasing the maximum page size jeopardize operations that we currently
consider safe? Or does it just add a - though not reliable - plus?"

Yes to the first. The possibility to run into some serioius errors 'jeopardizes'
by the given factors.


HTH. Maybe the configuration solution (see 2) would be good, i begin to
favourize it. Comments?

I think making the option to increase the maximum page size an option in the
config area is excellent.  That way you can have people like myself who have
wanted it for years able to use and test the option.  A warning in the config
area where you turn it on and off saying it is an alpha option would discourage
those who didn't need it.  You could also say feedback would be appreciated on
the use of the option.

I'd rather have the option available so I could at least try it out than to not
have it at all.
Thanks for your time!

note that the idea was to add an option to cofnig files, not to configuration user interface.
i generally like easy accessible options, but in this particular case having it hidden and making 
users actually find out that it exists seems a good idea ;)

mbayer -> aw: If (!) it is true that possible errors will occur only (!) with
pages > 119 cm, but not with pages =< 119 cm, I would plea for increasing the
limit to some reasonable bigger value, like 5 m, ASAP.

Given the possible impacts of this decision, I understand that you don't like to
make this option too obvious in the UI. OTOH I'm not happy with these hidden AKA
undocumented features: If it is already a risk to set the page size up to > 119
cm, users should not have to manipulate a configuration file manually for that,
because this is very risky, too.
Maybe this will do: in the page size dialogue, you can't increase the size to >
119 cm using the arrows, but the dialogue will accept it if you type in the
value directly.

Are we talking about a segfault and OO just crashing if the error occurs or just
something on the page not being where you want it?  Seems that 99% of what
people will do will be in the low error area of page sizing.  Only the people
who go way far out in page width will have the possibility of major problems.  I
like making the option very accessible and noticeable.  Just have a note right
there stating why the limit is what it is and that the limit will go away in
v3.0.  Hidden config options are bad since they tend to not get used.  Then, how
will developers get the feedback on the option if only a few use it?  This
should get the same attention any other part of OO should get.  I can make the
page as large as I want right now with hacking the XML and then exporting to a
PDF.  So, let's not use hidden options but keep the configuration as plainly
visible as possible.

AW: Sorry for the late answer, i was absent due to a bad flu. Bu t here we go:
AW->dowhurst, richlv: Yes, the current idea is to add to the config files. This
is the recommened way for options whereby the most visible ones get an UI then
which changes that config values. So, adding the config values is the right way
anyways, if we put an UI on it now or later. So i propose:

a- add the values to the config files
b- expand the default to 5x5 meters for convenience
c- document it there (config items allow extensive, specific comments)
d- do not add an UI, this may be done in 3.0 (when we are on IEEE)

AW->mbayer: I think something like using different user interaczions on the
value changing UI elements is no good style.

AW->dowhurst: Problem is not disappearance, but that for truncated values
objects (e.g. polygons and lines) tend to reach uncontrolled over the complete
page region, e.g. some points by error are left of the page whereby the object
(and the correct points) are on the right side which makes the view scrambled
and completely useless for further editing. This may happen in X and Y, creating
objects which cover the whole 5x5 meters.

BTW: 99% is a guess anyways, it may be somwhere else. But just stay at 99% and
multiply it with 10 million users. We have made the experience that - due to the
broad use base - what may get wrong will get wrong, just by usage count...

*** Issue 75284 has been marked as a duplicate of this issue. ***

*** Issue 50245 has been marked as a duplicate of this issue. ***

I am interested to work with no size limitation. Not for printing large papers,
but for drawing big sheets.
At this time (119 x 119 cm) I need for some drawings 5 separate sheets. Not very
amusing.

May i suggest making the page size a configuration item then ? Leave the default
size as is, but if someone wants to have a larger maximum, he can do so at his
risk. But at least we should solve this issue somehow after 5 years, especially
since it has a high number of votes.

I also suggest to change this.

I don't see double precision on the horizon for 3.0 yet. I agree fully with AW
that there is a risk, getting bigger as used page size grow. BUT that is more a
technical standpoint. From a user standpoint currently it is worse as he does
not have the chance to change the size to what he wants. Even if it may not work
at the size he wants he can't even try it. And if there are errors they will not
occur for the majority of the users.

So my vote is to change the maximum size to something like 100mx100m ASAP and
that "should be enough for anyone"(tm) doing banners and stuff. If you like to
design your own space ship, for your own sake, buy a CAD application!

For everyone who is desperate now, I never happen to have a printer printing
more than A3 (maybe except my first C= MPS801 which had unlimited lenght
depending on the paper :). But there must be something like 'fit to print'. So
if you only get the aspect ratio correct there should be no problem choosing any
size that is smaller and later scale it by the printer driver. If you need
correct measures, try the scaling feature of draw which you can choose from
tools options.

The current target of 2.3 seems reasonable as it is the next feature release.

AW: Preparing to change in aw051. I tend to do what cl issued. It's simple, it
can be done with reasonable effort, it does not need future effort for
introduced settings in configurations. My only thought was when people would run
into problems. Since cl does not take this as problematic, i will stop seeing it
as problematic, too. Do not protect the use too much.
AW: Adding to aw051 for preparation.

AW: Adding svx and officecfg. Dialog is SvxPageDescPage, ressource is
RID_SVXPAGE_PAGE (page.src). Up to now maximas for the spin field are only
defined in the ressource file.
AW: Remoing setting Maximas in ressoure file
AW: Adding setting Maximas (SetMax()) in SvxPageDescPage::SvxPageDescPage
AW: Also adding Margin Maximum settings; these are also Hard-coded ATM.
AW: Getting officecfg...

AW: Added to Common.xcs, Drawinglayer group:
			<prop oor:name="MaximumPaperWidth" oor:type="xs:int">
			<prop oor:name="MaximumPaperHeight" oor:type="xs:int">
			<prop oor:name="MaximumPaperLeftMargin" oor:type="xs:int">
			<prop oor:name="MaximumPaperRightMargin" oor:type="xs:int">
			<prop oor:name="MaximumPaperTopMargin" oor:type="xs:int">
			<prop oor:name="MaximumPaperBottomMargin" oor:type="xs:int">
and the corresponding default values.
AW: Adding svtools for drawinglayer options...

AW: So, here is the plan:
- Add MaximumPaperWidth, MaximumPaperHeight, MaximumPaperLeftMargin,
MaximumPaperRightMargin, MaximumPaperTopMargin and MaximumPaperBottomMargin to
office configuration
- Set defaults for Page Width/Height to 100x100 meters, Page margins stay at
9999 (99,9 cm)
- Read Maximas for the fields in Page dialog from the configuration

This allows usage of the big values (100x100 meters) for everyone, but enables
us to reduce it again when massive problems show up. It will be necessary to
test it and get feedback from early OOo versions to decide how to set defaults
for 2.3 release.

aw,
So, we should download the latest CVS for testing the new code or is there a
particular build we should acquire?  I'm definitely ready to try this on 36"x56"
posters.
Dow

AW->dowhurst: Hoooh! You are fast! ATM i am still working on the code and i
planned some other fixes on that CWS. Normally, such a CWS will run for 2-4
weeks. Then the testing (QA), nomaination, integration. It will some time later
be integrated in on eOOo version. When You want to test right now, You would
have to get the changes from CVS and build the modules Yourself for Your target
version....
AW: Please be patient. I will definitely need Your help for testing before 2.3
version, but it's still too early. I will keep You all informed here, promise :-)

AW: Some first imprtessions:
- The DrawingLayer itself males less problems than i feared
- Zoom is a problem. Not zoomin gin, but zooming out. The minimum zoom is 5%,
normally Okay. On 5x5 meters, You have no chance to see the whole page anymore...
- Printing is a biiig problem. Printing to multiple Pages with 5x5 meters did
not finish (2 gig memory used -> GPF). Could manage to get 2,5x2,5 meters
printed, though, but it's sloooow...

AW: Investigating for the minimum zoom. Is it technically necessary or just an
old relict? Getting SD with debug...

AW: Another test: Created a draw with 100x100 meters, added shapes on the
'Wiese' top left and bottom right -> save/reload -> Shapes are okay. Problem is
that the top-left shape shows an X-Position of 4739.5 (positive) what is wrong.
It is still at the correct place (Y is -4998,5). I will have to investigate what
goes wrong with X-Position here...

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...

Alternatively i can stay at 5% and just live with not being able to see the
whole page in the window. Will discuss with CL and UserExperience.

AW: Discussed with CL. I will take 3x3 meters as new default, that size is
completely visible at 5% and ca. 1000x800 pixels. People who want more will be
able to do more by changing the registry entries. This will protect 'normal'
users to reach a state where zoom gets a problem. I will also write a follow-up
task for zoom -> #i76912#.
AW: 3x3 is also the size up to which more or less the printing works, so it's a
good value...

AW: Changed defaults to 3x3m, added description incommon.xcs that increasing
this value is on own risk...

AW: Checked in changes so far. I will need to experiment a little bit (with draw
and impress)....

AW: I found no obious other problem s with 3x3m, so i assume this one as done
(Yippie :-).

AW->WG: Please verify. There are in principle two things:
(1) New draw/impress, open Page/Page Setup dialog, on TabPage Page, travel to
Width/Height, PgUp -> new maximum of 300 cm.
(2) The usage of the limits in MaximumPaperWidth/MaximumPaperHeight in
share\registry\schema\org\openoffice\Office\Common.xcs, also
MaximumPaper(Left|Right|Top|Bottom)Margin. Do not forget to delete the cache (!).

AW: WG asked me for changing to CGU, doing so.

hm, one more simple stupid question: why limitate to 3 x 3 m? Why is there any
limitation nessesary? - I'm not asking about printing, but e.g. for exporting to
pdf. I have to handle very large drawings (flowcharts) without printing needed
but for export to pdf to archive and share it.

there are a lot of comments, so finding out the reasons and solution can be 
hard :)

to make it worse, comments in issuezilla are not numbered, so i can't refer you 
to comment number thisandthat.

basically, search for a string "from aw Thu Feb 1 17:37:21 +0000 2007" - i 
believe that is a pretty thorough explanation of the nature of the problem.
read further to find out the solution. you will be able to increase size more 
by editing a file, but that will introduce a risk of running into problems. so 
file editing kinda tells you "don't come screaming if your objects jump around"
 :)

CGU: Verified in cws aw051

CGU: Integrated in src680m225

*** Issue 45074 has been marked as a duplicate of this issue. ***

I see the text-boxes for page width and height have been limited to 300 - so too
limit sized to 300cm x 300cm (or 3m x 3m).
But when setting OO options to Inches you can effectively enter 300" x 300",
giving you 7.62m x 7.62m).
Was this intended?

I see the text-boxes for page width and height have been limited to 300 - so too
limit sized to 300cm x 300cm (or 3m x 3m).
But when setting OO options to Inches you can effectively enter 300" x 300",
giving you 7.62m x 7.62m).
So the limit is not 3m x 3m?

Quite funny... What I read is solving my problem I guess... I can not write a A3
page... because, I am currently using the "millimeter" unit... So limit is
300mm... A3 being something like 30cm*40cm... So if i pass to centimeter unit,
should it work? ... suspens... Working... Ok... quite funny... nevertheless it
does not look quite serious to have to use such a trick...

Please update to a more current version where this problem is solved.