incorrectly placing the component attribute on the printout

[Jacek Pluciński]

gschem version: 1.10.0 (g1919a45)

reproduction:
 - create new file
 - add element: Library/Basic devices/aop-std-1.sym
 - print to the file with pdf format
 - compare the position of the attribute 'U?'
   (the position in gschem window != the position on the printout)

The incorrect location of the 'U?' attribute can also be seen in the print preview.

[Roland Lutz (rlutz)]

I can't reproduce this, sorry.

Could you please provide more information (operating system and library versions used, the .sym/.sch/.pdf files in question, screenshots of the file in gschem vs. the print preview)?

[Jacek Pluciński (j69p)]

Hello

I'm sorry to reply so late.

This test has been done with:
 - the gschem version g1919a45 (latest stable, from arch package)
   and ga8039b6 (compiled with gcc version 9.2.0),
 - the freshly updated version (20191126) of Arch Linux x86_64 (KDE and LXDE)

I allowed myself to attach:
 - ex1.(sch|pdf) - the example schema and print with any first component from standard library,
 - ex1_sch2pdf.png - shows diff beetween sch and pdf,
 - ex2.png - the example comparison for a more complex schema.

Thanks for interest and best regards
Jacek

[Jacek Pluciński (j69p)]

I just downgraded the geda to the version 1.8.2 ..
the same example looks correct on the ps printout
.. of course, I mean the location of the attribute 'U?' only.
I'm not sure, but maybe that excludes the system libs impact :|

[Roland Lutz (rlutz)]

It's me who needs to apologize for replying late.

Ok, this looks bad. I notice how some text, but not all, and only the Y component of the position (the X component for vertical text) appears to be affected.

My guess would be that it's a bug with vertical alignment depending on the anchor (top, middle, or bottom). Could you please try the attached testcase to verify this?

[Roland Lutz (rlutz)]

Please do not change the bug status back to “New” once it was set to “Incomplete”. From here, it should be only set to

- “Confirmed” if someone else has verified the problem
- “Triaged” if all information necessary to understand and work on the bug has been provided
- “In Progress”, “Opinion”, “Invalid” etc. as appropriate

[Jacek Pluciński (j69p)]

Hello
The attachment contains a printout of the testcase.sch.

[Jacek Pluciński (j69p)]

The attachment contains a printout of the testcase.sch
after changing the font size of the text in line: 6 (from the bottom), column: 1)
from 10 to 8 only.

[Jacek Pluciński (j69p)]

I changed the testcase.sh a little bit (attachment) ..
the text "upper left" has been moved to up and left etc ..
and row with column number has been added to the string.

After several tests I noticed that:
 - the only text aligned "lower" (left, middle and right) is rendered incorrectly
 - the plain text as well as attributes are shifted
 - the text with exactly size 8 is properly rendered
 - the unwanted offset depends linearly on the size of the text
 - only the coordinate Y is incorrect and always reduced

[Roland Lutz (rlutz)]

These are interesting results. The fact that only the lower alignments are affected means that either the font descent or the height of the logical text bounding box are calculated incorrectly. But why does this depend on font size?

You didn't attach the rendered result of your new testcase; maybe this could help understand the issue better. Also, I created and attached a new testcase with all font sizes from 1 to 20.

You can observe the font descent and logical text bounding box by adding the following lines to libgedacairo/edarenderer.c:

@@ -971,6 +971,15 @@ eda_renderer_calc_text_position (EdaRenderer *renderer, OBJECT *object,
   y_middle = y_upper - inked_rect.height / 2.; /* Middle of inked extents */
   y_lower = descent - logical_rect.height; /* Baseline of bottom line */

+ fprintf (stderr, "%.3f %.3f ",
+ (double) y_lower / PANGO_SCALE,
+ (double) descent / PANGO_SCALE);
+ fprintf (stderr, "[%.3f %.3f %.3f %.3f]\n",
+ (double) logical_rect.x / PANGO_SCALE,
+ (double) logical_rect.y / PANGO_SCALE,
+ (double) logical_rect.width / PANGO_SCALE,
+ (double) logical_rect.height / PANGO_SCALE);
+
   /* Special case flips attachment point to opposite corner when
    * the text is rotated to 180 degrees, since the drawing code
    * does not rotate the text to be shown upside down.

Maybe a pattern emerges here.

[Jacek Pluciński (j69p)]

"The text with exactly size 8 is properly rendered" is no longer true :)
The most interesting is that the gaf exports to pdf correctly ..
 we probably have a catch.
I modified a bit fprintf:
 fprintf(stderr, "'%s', y_lower: %.3f, descent: %.3f ",
 pango_layout_get_text(renderer->priv->pl),
 (double) y_lower / PANGO_SCALE, (double) descent / PANGO_SCALE);
 fprintf(stderr, "[%.3f %.3f %.3f %.3f]\n",
 (double) logical_rect.x / PANGO_SCALE,
 (double) logical_rect.y / PANGO_SCALE,
 (double) logical_rect.width / PANGO_SCALE,
 (double) logical_rect.height / PANGO_SCALE);
run .. and found nothing yet :/
The attchment contains pdf and stderr form gaf and gschem.

[Jacek Pluciński (j69p)]

The testcase4 shows that
the offset is almost linear function of the font size.

[Jacek Pluciński (j69p)]

The testcase5 is most interesting.
There are only two strings and the line on schema.
When the string sizes are the same the schema are printed fine.
When the string sizes are different ..
the second string (second in the schema file) is shifted down.
BTW: the gaf printing is ok for all cases.
I'm comparing export.c/static void export_draw_page (..)
with x_print.c/static void x_print_draw_page (..)
but this code is new for me .. it's not easy to find diffs :/

[Jacek Pluciński (j69p)]

After analyzing exactly the testcase5 ..
with a standard call stack when printing to pdf:
geda-gaf/libgedacairo/edarenderer.c \
eda_renderer_draw
 eda_renderer_draw_text
  eda_renderer_prepare_text
   eda_renderer_get_font_descent
the calculated descent (metrics->descent) in line 864:
 metrics = pango_context_get_metrics (renderer->priv->pc, desc, NULL);
has improper value for the second string from testcase5.
I'm sure the function argument *desc is valid
and renderer->priv->pc looks good .. what is wrong?

[Roland Lutz (rlutz)]

Thank you for your analysis! This is really helpful.

There's a lot going on before Christmas, so I won't be able to look into this for another few days. I apologize and hope you can understand. I'll look into this as soon as I can.

[Jacek Pluciński (j69p)]

I wanted to avoid it but I think .. I will spend Christmas with GDB :)
It is very likely that the Pango changed something in the context obj
and we will have to adapt to these changes.

I wish You all the best during Christmas and happy New Year!!!

[Wolter HV (wolterh)]

I can confirm this issue.

[Wolter HV (wolterh)]

Forgot this:
geda-gaf version 1.10.0-1

[Roland Lutz (rlutz)]

Turns out the Cairo matrix currently loaded when calling ‘pango_cairo_create_context’ or ‘pango_cairo_update_layout’ affects the text metrics returned by later ‘pango_context_get_metrics’ calls. :-|

fixed in 4acd8b76ddd75ef6f1a306a07c19d07a370dbe50
  (branch ‘stable-1.10’)

[Roland Lutz (rlutz)]

fixed in gEDA/gaf 1.10.1