[Qgis-developer] printing issues

[Steven Bell]

I apologize for being so slow to answer.

The polygon border problem should be fixed.  Like the lines, it only matches
when both the map and legend are in render mode.
I think there are time when it's good to be able to set render mode
independently, but it would be helpful to have a "set all items to
render/set all items to cache" option.

The label positioning is slightly more difficult, and I haven't had time to
work on it.  Thanks for the dataset though.
As far as I can tell, the font nastiness occurs with Qt on Ubuntu.  I've
created a simple test program which reproduces the problem, so it's not a
QGIS bug:

Steven Bell wrote:

> If some other Linux users could run my font test program below, that
> would be helpful.  Let me know your Linux distro, Qt version, and
> whether the text came out garbled.
> A Linux binary is here: http://botsnlinux.googlepages.com/QT_Fonts , and
> source code is here: http://botsnlinux.googlepages.com/QT_Fonts.zip
> <http://botsnlinux.googlepages.com/QT_Fonts.zip>

 I have this terrible compulsion to convert Qt C++ code into Python/Qt
code, so my Python version of Steven's code is here:

http://www.maths.lancs.ac.uk/~rowlings/Geog/Qgis/QT_Fonts_Python.zip<http://www.maths.lancs.ac.uk/%7Erowlings/Geog/Qgis/QT_Fonts_Python.zip>

[files unzip into current directory so unzip this in a sub-folder of its
own. there's only three files in it]

 unzip, run "python main.py" and if you have PyQt4 it should do the
same as Steven's C++ example - ie on my Ubuntu box show text badly when
scaling small point fonts up to large pixel sizes.

Barry

I added a bit of code which checks the default font size and limits it to a
minimum of 6.  With some settings, we were getting sizes around 3, which was
totally unreadable.  6 may still be too small, but at least it's a little
better.
Also, I think I have fixed a bug which sometimes prevented the addition of
more than one map to the page.
Steven


On 7/29/07, Maciej Sieczka <tutey at o2.pl> wrote:
>
> >>> Maciej wrote:
> >> Maciej wrote:
> > Paolo wrote:
> Steven Bell wrote:
>
> > Hi all, Thanks once again for your testing.
>
> Cheers!
>
> I'm just back from a short vacation on a rainy Baltic coast. It was
> cool (indeed).
>
> >>> However, either in "cache" or "render" mode in the *map
> >>> composer* line widths on the legend and on the map *do not
> >>> correspond*. On the legend it's always thicker.
>
> > This is a known problem for cache mode, since the cache is created
> > at a variable resolution and then variably scaled.  In render mode,
> > the line widths appear to correspond.
>
> You are correct. The reason why I thought that the line width on the
> the lengend and on the map don't correspond in render mode for me
> either, is that I have just found out that one has to turn on the
> render mode *separately* for the legend and the map. I didn't know that
> before. So my fault. However, IMO it's questionable if switching
> between the render and cache mode should be print-composer-wise, or
> sperate for the legend and the map as it is currently. What do you think?
>
>
> > I'll try to look into it more when I get a chance (unfortunately,
> > that may be a few weeks).
>
> No problem at all. I'm glad you might be interested in looking into it.
>
> >> the border of polygons however it is not synchronized between
> >> legend and map
>
> > I changed the line for the polygon outline to be a "cosmetic pen"
> > (1px wide, regardless of scale) when the line widths were getting
> > out of hand.  Since that should be fixed now, I can probably put the
> >  original line widths back.
>
> I think that it would be consistent this way. If one really wants 1px
> wide border for his polygons on the printout, he can set the border
> width to 0 in the project.
>
> >>>> 2. labels placement and size in the map canvas not always
> >>>> corresponds to that in the map composer and printout
>
> >>> Still valid. See the following attachments:
> >>>
> >>> labels_mapview.png labels_composer.png labels_pdf.png
> >>>
> >>> They show how the labelled points look in the QGIS map view, map
> >>>  composer and in the output pdf, respectively. Each looks much
> >>> different. Could it be at least fixed so that the view in the
> >>> map composer and the resulting pdf looked similar?
>
> > I haven't done much testing with vector labels, so I'm not too
> > surprised some bugs still lurk there.  If you could send me some
> > simple projects which reproduce the problem, that would be great
> > help.
>
> Please find the points shapefile attached. It's from the free
> "Spearfish" GRASS dataset (BTW, the new "Save as shapefile" worked
> great for the original GRASS vector layer!). Display labels from field
> 'str1' and try to print.
>
> I'm not sending you the project with labels set on, as it shows there's
> a bug that once you set labels on, save the project and reload it, the
> labels are not displayed anymore and I can't find a way to make them to
> - besides starting the project from scratch again.
>
> >>>> 3. vector point symbols get rasterized in the printout
>
> >>> Still an issue. Is it fixable?
>
> >> moreover, point size is much larger (1.4x? 2x?) in the legend than
> >> in the map, and larger in the pdf.
>
> > Unfortunately, I don't think we can fix this for 0.9.  It will
> > require some significant changes to the symbology and rendering,
> > which has the potential to break things.
>
> Really too bad. This is quite an issue.
>
> >>>> 4. irregular letter spacing in the printout
>
> >>> Still the case. See the attachment spacing_pdf.png. Moreover,
> >>> layer's name is to close to categories' names below, overlapping
> >>> it a bit.
> >>>
> >>> Also, in the composer *the very same legend* before printing to
> >>> pdf looks completely different (font_composer.png) and rather
> >>> corrupted. Can this avoided? What's strange, if I zoom in in the
> >>> map composer once or twice, the legend's font starts looking
> >>> same as in target pdf, hmm. The same problem applies to
> >>> scalebar.
>
> > The ugly font bug strikes again!  What operating system and Qt
> > version are you using?
>
> Ubuntu Dapper, QT 4.3 built from source (qconfig.pri attached in case
> it matters what features where compiled).
>
> > I have exactly the same problem, and I don't think there's much we
> > can do.  (I'm running Ubuntu with Qt 4.2/4.3)
>
> So a QT bug?
>
> >>> Another, smallish, issue which remains is that the default font
> >>> size for legend "6" is always too small too be any readable. I
> >>> guess defaulting to at least 8 is a better idea.
>
> >> agreed. also, default font (sans-serif?) does not appear optimal
> >> on many machines.
>
> > I'm pretty sure Qt provides the default font, so we'd have to
> > manually override this.  I'll see if we can do this in a simple,
> > cross-platform way. The font size is calculated based off of the map
> > scale, and often is less than 6.  Perhaps some code to limit the
> > default to a minimum of 8 would be helpful.
> >
> > I'm not going to have much time to work on QGIS in the next few
> > weeks, but I'll try to fix what I can for 0.9.
>
> Understood. Many thanks for getting the print composer rolling again
> and good luck.
>
> Maciek
>
>
> #configuration
> CONFIG +=  no_mocdepend release stl qt_no_framework
> QT_ARCH = i386
> QT_EDITION = OpenSource
> QT_CONFIG +=  qt3support accessibility opengl minimal-config small-config
> medium-config large-config full-config reduce_exports ipv6 clock-monotonic
> mremap getaddrinfo ipv6ifname getifaddrs system-jpeg system-png png
> system-tiff system-freetype system-zlib nis cups iconv glib openssl x11sm
> xshape xinerama xcursor xfixes xrandr xrender fontconfig tablet xkb release
>
> #versioning
> QT_VERSION = 4.3.0
> QT_MAJOR_VERSION = 4
> QT_MINOR_VERSION = 3
> QT_PATCH_VERSION = 0
>
> QMAKE_RPATHDIR += "/usr/local/qt4/lib"
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20070923/f796fbaa/attachment.html