Hello!
Whatever scale I select in print preview the drawing remains zoomed to its extents (in relation to the paper size). To be able to print scaled drawings is a core function of any CAD program, so I believe this is an urgent problem to solve. Perhaps related to ID: 3470990 ?
I use Ubuntu 12.04 64-bit, and I have reproduced the problem with LibreCAD 1.0.1 as well as with the daily build currently at Version: master SCM Revision: 2.0.0alpha3 Compiled on: Apr 25 2012.
can not reproduce this.
Please provide detailed steps to show the bug behavior.
The steps are:
1. open 'print preview'. The entire drawing is displayed with its extents fit to the white background denoting the paper.
2. select one of the predefined scales in the drop-down menu box, for example '1:200', or type it in manually.
3. the drawing remains with its extents fit to the paper. Hence ignoriing the scale set in previous step.
This bug makes it difficult or impossible to print the drawing, or parts of it, in other scales but what happens to be given by the extents of the drawing in relation to the paper.
I can reproduce the bug on three different systems: Ubuntu 12.04, Ubuntu 11.10, and Windows XP sp3. On all three systems I have the latest daily builds of LibreCAD, and on the first I have tried version 1.0.1 as well as the latest daily build as of 25th of April.
If you truly can't reproduce this, then please explain the steps for printing in different scales, what your specs are, etc.
Regards, Jkop
Hope this is detailed enough.
Hello again
I just noticed that drawings drawn in LibreCAD scale and print without the problem whereas the imported drawings I have been trying to print just won't scale. They're simple line segments of a site plan that I got from our teachers who might have produced them in AutoCAD or the like.
I can send you an example drawing if it helps identification of the problem. Just tell me where to mail it.
Regards, Jkop
So perpahs the problem can be isolated to some property of imported dxf drawings, for drawings made from scratch with LibreCAD seem to scale and print just as they should, but the drawing I've imported into LibreCAD just won't scale at all. It scales neither when I have deleted all entities, created new layers, and drawn new lines, nor when I copy and paste the lines into an entirely new drawing. So what could be in those lines causing such a problem?
Hi jkop,
Please add a example file not working to find the problem.
Cilck in "Attached File" near the bottom of the page to add
red and white lines were imported into LibreCAD
Hi, please find attached file below.
I might add that I recently noticed a message in the console while trying to scale some of the lines pasted into a new drawing:
"Scale ratio too large. Keep the old..."
Furthermore after a few more attempts to copy-paste lines into a new drawing I could actually scale them in print preview. It worked!! But not every time. As if one has to click a few more times in the scale box to get it started... :s
we need redesign the painter system for efficiency.
to fix bug 3450333 , paper scale factors too large are rejected
pushed in master branch, a fix for bug#3450333. This should relax paper scale restriction.
commit 1b7af53..0abe45f
It seems to work, thanks very much, dongxuli :)
Now I have also tried the stable release, 1.0.2, and can report that print preview scaling of my drawings does not work with the stable release either.
Furthermore, while the current daily build of LibreCAD allows scaling in print preview my particular drawings after yesterday's upgrade LibreCAD won't print print them anymore.
Perhaps this printing problem is also corelated to the large range for the scale factor in these drawings?
The print behavior is such that when signal is sent to the printer driver, it stops and disappears after a few seconds, as if the signal would be empty.
I might add that when selecting to printi to file (PDF, Postscript, or PNG), they all print empty documents (unless the drawing is created in LibreCAD, for then it works)
more fixes in master branch, commit: f7e708d..57a8c1d
refer to bug# 3522252 for further discussion and fixes.