Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect label vertical alignment for certain font sizes #2854

Closed
marisn opened this issue Feb 23, 2023 · 11 comments · Fixed by #2857
Closed

Incorrect label vertical alignment for certain font sizes #2854

marisn opened this issue Feb 23, 2023 · 11 comments · Fixed by #2857
Labels
bug Something isn't working C Related code is in C
Milestone

Comments

@marisn
Copy link
Contributor

marisn commented Feb 23, 2023

A row of vector points has labels shown next to them. Depending on the font size, some labels will be vertically shifted or all labels will be on the same line (as expected).
See screenshot with only one difference – for one row font size is set to 21px and for other – 22px. Vertical alignment should be identical for all letters but is different for the 21px case.
21px

@marisn marisn added bug Something isn't working C Related code is in C labels Feb 23, 2023
@nilason
Copy link
Contributor

nilason commented Feb 24, 2023

I have tried to reproduce this with no success. Lines up nicely with various sizes, font types...

@marisn
Copy link
Contributor Author

marisn commented Feb 24, 2023

On my system this happens with all fonts only the size needs to be adjusted as for each font sizes that trigger the issue differ. I tried both cairo and PNG renderers and both are affected. This issue has been reproduced on another Linux system too. My Debian uses libfreetype6-2.12.1
This is how letters with bottom left alignment look like:
image

@nilason
Copy link
Contributor

nilason commented Feb 24, 2023

This is what I've been using (and variants of it):

#!/bin/sh

echo "1|629880|222510|a
2|629882|222510|b
3|629884|222510|c
4|629886|222510|d
5|629888|222510|e
6|629890|222510|f
7|629892|222510|g
8|629894|222510|h
9|629896|222510|i
10|629898|222510|1
11|629900|222510|2
12|629902|222510|3
13|629904|222510|4
14|629906|222510|5
15|629908|222510|6
16|629910|222510|7
17|629912|222510|8
18|629914|222510|9" | v.in.ascii input=- output=labelmap cat=1 x=2 y=3 --overwrite

g.region e=629916 w=629879 s=222508 n=222512 res=1
d.mon start=wx0

d.vect map=labelmap color=0:29:57:255 width=1 \
    attribute_column=str_1 label_bcolor=13:0:200:255 \
    label_size=21 \
    yref=center xref=left

I now realise the yref and xref seem not to take effect for me.

@marisn
Copy link
Contributor Author

marisn commented Feb 24, 2023

I now realise the yref and xref seem not to take effect for me.

That will depend on size of computational region, font size, output size and phase of the moon. With your data I managed to get even so ridiculous output:
image

@nilason
Copy link
Contributor

nilason commented Feb 24, 2023

That will depend on size of computational region, font size, output size and phase of the moon. With your data I managed to get even so ridiculous output:

Not to forget which side you woke up on that particular morning :-)

I've been testing in nc_spm_full_v2alpha2, this is what it looks like for me:

out

@nilason
Copy link
Contributor

nilason commented Feb 24, 2023

Interestingly, there was a ticket related to my particular issue 11 years ago: https://trac.osgeo.org/grass/ticket/1667

@marisn
Copy link
Contributor Author

marisn commented Feb 24, 2023

The logic of alignment in d.vect is totally bogus. If I disable Yoffset, the issue is gone

if (lattr->xref == LCENTER)

@veroandreo
Copy link
Contributor

That will depend on size of computational region, font size, output size and phase of the moon. With your data I managed to get even so ridiculous output:

Not to forget which side you woke up on that particular morning :-)

I've been testing in nc_spm_full_v2alpha2, this is what it looks like for me:

out

I get something similar in Fedora 36. No effect of yref and xref, no matter what I put there, the output is the same.

@nilason
Copy link
Contributor

nilason commented Feb 24, 2023

I have now corrected v.in.ascii and g.region in above example script, and now alignment seems to work.

@wenzeslaus
Copy link
Member

I have now corrected v.in.ascii and g.region in above example script, and now alignment seems to work.

@nilason Can you please share your corrected code so we can test #2857? Script or notebook in the source code might be good basis for testing in the future.

@nilason
Copy link
Contributor

nilason commented Feb 24, 2023

I have now corrected v.in.ascii and g.region in above example script, and now alignment seems to work.

@nilason Can you please share your corrected code so we can test #2857? Script or notebook in the source code might be good basis for testing in the future.

I referred to the testing script above (#2854 (comment)). Now I have hopefully corrected/updated it in-place. (Initially made some last minute correction without testing when I posted it).

Did some further testing, sometimes it works, sometimes not. I even hade the jumpy result as @marisn . But I haven't been able to see some pattern.

@landam landam added this to the 8.4.0 milestone Nov 20, 2023
HuidaeCho pushed a commit to HuidaeCho/grass that referenced this issue Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working C Related code is in C
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants