After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 538499 - also font-size issues with cairo renderer
also font-size issues with cairo renderer
Status: RESOLVED FIXED
Product: dia
Classification: Other
Component: general
devel
Other Linux
: Normal critical
: 0.97
Assigned To: Dia maintainers
Dia maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-15 19:56 UTC by Hans Breuer
Modified: 2009-01-09 22:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
spreading more magic numbers through the code (1.49 KB, patch)
2008-07-06 16:29 UTC, Hans Breuer
none Details | Review

Description Hans Breuer 2008-06-15 19:56:23 UTC
Switching between standard gdk display renderer and the new cairo renderer shows a signififcant mismatch in font-size. It seems as if the .7-hack which is also applied in the cairo renderer does only solve the issue on windows.

Looks like the freetype based renderers (libart and gdk on Linux) are creating the smallest texts. Unfortunatly they are kind of the standard. Fixing the issue on a level above should also fix the size mismatch with the svg renderer, see bug #345538. WOuld be nice to finally fix this before releasing 0.97.
Comment 1 Hans Breuer 2008-07-06 16:29:50 UTC
Created attachment 114067 [details] [review]
spreading more magic numbers through the code

patch I don't want to apply, just working around the issue in the cairo renderer
Comment 2 Hans Breuer 2009-01-09 22:39:22 UTC
Finally implemented the right fix:

2009-01-09  Hans Breuer  <hans@breuer.org>

	* lib/font.h : declare dia_font_get_size()
	* lib/libdia.def : export it
	* lib/font.c : use pango_font_description_set_absolute_size() - the 
	magic factor which tried to compensate for fontmap resolution issues 
	_and_ the difference between Dia's intention of "font_height" and 
	Pango's "font size" is gone. 
	There is a much less magic factor just compensating the second issue. 
	Dia's font-height always meant something like line height, i.e. a 
	good difference between two consecutive lines baselines (Pango itself 
	is using line_height=ascent+descent).
	Instead of searching the right size for a given height a new factor 
	got introduced, which unfortunately changes the font-size on win32 
	and X, but all this finally fixes bug the OS dependent part of 
	bug #108293

	* plug-ins/cairo/diacairo-renderer.c : use dia_font_get_size() and 
	pango_font_description_set_absolute_size instead of magic number 0.7
	fixing bug #538499
	* plug-ins/wmf/wmf.cpp : same here