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

8va cause text overlap #44

Open
yurivict opened this issue Aug 30, 2017 · 18 comments
Open

8va cause text overlap #44

yurivict opened this issue Aug 30, 2017 · 18 comments

Comments

@yurivict
Copy link
Contributor

yurivict commented Aug 30, 2017

This code [ h2/4 \oct<+2> c2 e/2 \oct<0> e1/2] renders with overlap:

8va

@yurivict yurivict changed the title 8va cause text overrun 8va cause text overlap Aug 30, 2017
@arshiacont
Copy link

+1

@yurivict
Copy link
Contributor Author

Also, maybe I am mistaken, but isn't is supposed to also print 8va?

@arshiacont
Copy link

No since you are asking for \oct<2>. 8va would be oct<1>

@yurivict
Copy link
Contributor Author

\oct<1> prints 8, not 8va.

@arshiacont
Copy link

8 or 8va is fine and equivalent to oct<1>. I am not an expert! Just know that '8' is fine but 8va is more common.
Oct<2> should give 15va.
In this link, the three measures are thus equivalent: https://en.m.wikipedia.org/wiki/File:Ottava_Ex.png

This said, the rendering overlap you mention should be avoided! I think it's a minor bug that Dominique can get rid of quickly... .

@dfober
Copy link
Member

dfober commented Aug 31, 2017

The problem is that I can't reproduce. Please, give details about the OS and guidolib version.
Regarding the 8 or 8va display, that is easy to change and could be also an option (i.e. a tag parameter).

@yurivict
Copy link
Contributor Author

OS is FreeBSD 11.1-STABLE.
guidolib 76489e5

@dfober
Copy link
Member

dfober commented Sep 1, 2017

Sorry but I can't reproduce (tested on MacOS, Windows 10 and Debian 8). I don't have any station installed with FreeBSD.
Regarding the 8 and/or 8va, I'll check what the notation gurus say about that (notably Gould) but for the moment I'm away from my desktop. Next week...

@yurivict
Copy link
Contributor Author

yurivict commented Sep 1, 2017

Sorry but I can't reproduce (tested on MacOS, Windows 10 and Debian 8). I don't have any station installed with FreeBSD.

Might be because of font differences?

@dfober
Copy link
Member

dfober commented Sep 1, 2017

might be ! I'll check how the metrics are collected.

@dfober
Copy link
Member

dfober commented Sep 1, 2017

I've changed the metrics. Tell me if it solves the problem on your side.

@yurivict
Copy link
Contributor Author

yurivict commented Sep 1, 2017

I've changed the metrics. Tell me if it solves the problem on your side.

Still a problem, it overlaps even more.

@dfober
Copy link
Member

dfober commented Sep 4, 2017

strange (that it overlaps more),
actually the text height is collected by the GROctava constructor:
GROctava::GROctava fTextHeight: 83
could you check what you get?

@yurivict
Copy link
Contributor Author

yurivict commented Sep 4, 2017

I added this line in the end of GROctava::GROctava:
printf("fTextHeight=%f (fText=%s)\n", fTextHeight, fText.c_str());

It printed:

fTextHeight=51.000000 (fText=8)
fTextHeight=0.000000 (fText=)

@dfober
Copy link
Member

dfober commented Sep 5, 2017

The first line should correspond to \oct<1> and the second one to \oct<0>
and all that looks normal.
Could you manually force the fTextHeight value (e.g. to 100). If that solves the issue, it means that the problem comes from the font management (I guess you're using the Cairo device).

@yurivict
Copy link
Contributor Author

yurivict commented Sep 5, 2017

With fTextHeight=100., the leftmost hyphen is over "15". I use guido2svg.

@dfober
Copy link
Member

dfober commented Sep 5, 2017

ok, I didn't checked with the svg device. Now I can reproduce.

@dfober
Copy link
Member

dfober commented Sep 5, 2017

First point: you can set the INDEPENDENTSVG cmake option to yes: it solves the problem.
The default is no and in this case, the svg device uses Cairo to compute font extents and it looks like something is going wrong in this context. I'm investigating...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants