Forum > Lazarus

Lazarus Release Candidate 2 of 2.2.0

<< < (4/22) > >>

robert rozee:
attached is a revised version of wp's code, with fixed StaticText font (was default, now Courier New), and slightly changed PaintBox code:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TForm1.PaintBox1Paint(Sender: TObject);var I:integer;    W:integer;begin  Paintbox1.Canvas.Brush.Color := clRed;  Paintbox1.Canvas.FillRect(0, 0, Paintbox1.Width, Paintbox1.Height);  Paintbox1.Canvas.Brush.Color := clWhite;  Paintbox1.Canvas.Font.Assign(Label1.Font);  Paintbox1.Canvas.Textout(4, 4, 'This is underlined text.');  Paintbox1.Canvas.Font.Color:=clWhite;  W:=PaintBox1.Canvas.TextWidth('##');  for I:=0 to 4 do                                                      // 20 characters in total...  begin    Paintbox1.Canvas.Font.Style:=[fsUnderline];                         // two characters underlined    Paintbox1.Canvas.Textout(4+(2*I*W)  , 40, '##');    Label8.Caption:=IntToStr(PaintBox1.Canvas.TextHeight('#'));    Paintbox1.Canvas.Font.Style:=[];                                    // two characters NOT underlined    Paintbox1.Canvas.Textout(4+(2*I*W)+W, 40, '##');    Label9.Caption:=IntToStr(PaintBox1.Canvas.TextHeight('#'));  end;                                                                  // repeated 5 timesend;
the paintbox background is now red, so you can see the of boundary what Textout produces. also added is another line of text, with white text on a white background, highlighting the cases where the height of the text is different when underlining on/off. Note the values for TextHeight do not change, while the height of the output does. Also note (in magnified section, below) where the underlining starts one pixel offset from the left.

i vaguely feel that a good portion of the problem is something outside of Lazarus, when the underline is defined as being located below the bottom edge of the character cell. the problem doesn't seem to manifest in Linux.


cheers,
rob   :-)

wp:
There are two ways to draw text with Lazarus:

* Canvas.Textout /Canvas.TextRect: Debugging into the LCL you can see that it finally calls Windows.ExtTextOutW.
* DrawText(handle, ...): This finally calls Windows.DrawTextWAs the attached demo shows, the underscore issue occurs only with DrawText, not with Canvas.TextOut.

TLabel.Paint finally calls the DrawText method. I am aware that it has advantages in calculating the size of the bounding rectangle when wordwrapping is allowed. Maybe this was the reason why the creators of the LCL chose this method.

This leads to the idea that the reason for the issue is in Windows, and this is confirmed when I do the same test in Delphi XE10.3.3 which shows exactly the same behaviour.

I could imagine that the vertices of the font glyphs are defined either by floating point numbers or by large integers later scaled to the destination font size. Depending on how this is done exactly there may be round-off errors by one pixel which eventually may show or hide the underscore line.

Sounds bad...

On the other hand, as a remedy, we could increment the bottom of the rectangle returned by the DrawText method when DT_CALCRECT is included in the flags.

Since this is needed for Windows only, I'd recommend that you try the following steps:

- Load the file lcl/interfaces/win32/win32winapi.inc (You should make a backup copy of the changed file so that you can restore the original behaviour).

- Find the procedure TWin32WidgetSet.DrawText.

- Towards its end there is block "if lf.lfItalic > 0". Put the following code before this "if". It is supposed to move the bottom of the calculated bounding rectangle of the text by one pixel to avoid clipping of the underscore line.

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---    if lf.lfUnderline<>0 then      inc(Rect.Bottom); - Rebuild the IDE and run your tests again

- Report back whether it fixes the issue and whether you see any side effects (it seems to work for me).

prof7bit:
Has the naming scheme of the branch tags changed?

previosly it was

[main|t-fixes]_<version>

now with RC2 it has become

lazarus_<version>[_RCx]

The space in the about box was already quite small for a full git description, but now with this overly long tag name it has become very unreadable. I personally find "lazarus-" in the tag name (and thereby in the revision-"number") quite redundant, because what else would one expect to find in the Lazarus repository? Generally I believe the tag names should follow some consistent scheme that doesn't change with every release candidate, and they should not carry redundant information.

Was this new tag name merely an accident or was there really a naming scheme change? I suspect the former, but fortunately the tags can still be changed afterwards without impacting the revision hash or rewriting history.

Martin_fr:
No, they haven't changed.

Here is how the go (and you can look at the fixes_2_0 branch (and others), and see it's the same.

1) The very first commit is tagged: "main-0_0"

2) Each time a fixes branch diverges (each time the revision number in "main" changed, e.g from 2.1 to 2.3)
- the fixes branch's very first commit is tagged "t-fixes-n_n"
   (the "t-" is to distinguish from the branch name)
- the main branch is tagged: "main-n_n"

3) Each time a release is made from fixes (including RC)
a new tag is added to fixes "lazarus-n_n_n"  (one "_n" less for the first release on the branch)
(There was a discussion to make it "release-n_n_n", but that would not make a diff in the length of the tag)

This had been forgotten for the RC1 => therefore it had not been seen then.
(That RC1 tag should still be added...)

4) Feature branches (if long living) may also have a tag on their very first commit, so they do not report "main-n_n".

Martin_fr:
Maybe it can be shortened it the display....
Don't know.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version