Wrong positioning printing line of words in different colors

[laplace]

The StyledEdit document contains the following text line:

Black Red Green Blue Cyan Magenta Yellow

each word has the font color of the word.

When the text is printed each word starts at the left border again, so the words overlap each other.

The attached ZIP file contains the StyledEdit document (Test Page Color) and a PDF printout (Test Page Color.pdf)

[pulkomandy]

Any style change in a line will trigger this. Tabs are also resulting in strange things. Anyone with an actual printer plugged to an Haiku computer to check if this is a problem in StyledEdit, the print kit, or the PDF printer driver?

[jackburton]

Could be a problem in BPicture and/or BTextView. To know better, a minimal test should be extracted from the involved code in BTextView and added to the BPicture test suite we have already. OTOH, could be something in StyledEdit printing code, but I doubt, since it just uses BPrintJob.

[jackburton]

I don't know if it's related, but the PDF Print test page doesn't have any color in it.

[vidrep]

hrev50006 x86_gcc2 Printer: Epson NX625

I am still able to reproduce this problem

[pulkomandy]

I made tests with the "Preview" printer, and it shows the same problem. This rules out the PDF printer driver.

Then I used the DumpPrintJob test to dump the print job. Part of the output:

EnterFontState 
  SetFontFamily DejaVu Sans 
  SetFontStyle Book 
  SetFontSize 36.000000 
  SetFontShear 90.000000 
  SetFontRotation 0.000000 
  SetFontSpacing B_BITMAP_SPACING 
  SetFontEncoding B_UNICODE_UTF8 
  SetFontFace B_REGULAR_FACE 
  SetFontFlags none set 
  ExitFontState 
  SetPenLocation point (3.000000, 80.416016) 
  DrawString escapement_nospace 0.000000 escapement_space 0.000000 text: RED  
  EnterFontState 
  SetFontFamily DejaVu Sans 
  SetFontStyle Book 
  SetFontSize 36.000000 
  SetFontShear 90.000000 
  SetFontRotation 0.000000 
  SetFontSpacing B_BITMAP_SPACING 
  SetFontEncoding B_UNICODE_UTF8 
  SetFontFace B_REGULAR_FACE 
  SetFontFlags none set 
  ExitFontState 
  SetForeColor color r: 59 g: 177 b: 0
  SetPenLocation point (3.000000, 80.416016) 
  DrawString escapement_nospace 0.000000 escapement_space 0.000000 text: GREEN 
  EnterFontState 
  SetFontFamily DejaVu Sans 
  SetFontStyle Book 
  SetFontSize 36.000000 
  SetFontShear 90.000000 
  SetFontRotation 0.000000 
  SetFontSpacing B_BITMAP_SPACING 
  SetFontEncoding B_UNICODE_UTF8 
  SetFontFace B_REGULAR_FACE 
  SetFontFlags none set 
  ExitFontState 
  SetForeColor color r: 0 g: 0 b: 0
  SetPenLocation point (3.000000, 80.416016) 
  DrawString escapement_nospace 0.000000 escapement_space 0.000000 text:   
  EnterFontState 
  SetFontFamily DejaVu Sans 
  SetFontStyle Book 
  SetFontSize 36.000000 
  SetFontShear 90.000000 
  SetFontRotation 0.000000 
  SetFontSpacing B_BITMAP_SPACING 
  SetFontEncoding B_UNICODE_UTF8 
  SetFontFace B_REGULAR_FACE 
  SetFontFlags none set 
  ExitFontState 
  SetForeColor color r: 36 g: 71 b: 106
  SetPenLocation point (3.000000, 80.416016) 
  DrawString escapement_nospace 0.000000 escapement_space 0.000000 text: BLUE 

Notice how each DrawString is always just after a SetPenLocation. The pen locations are always at x=3, so at the left of the window, which is what we see in the printed data.

These are added by ​http://cgit.haiku-os.org/haiku/tree/src/kits/interface/PictureDataWriter.cpp#n456, which just uses the given location.

That location is from ​http://cgit.haiku-os.org/haiku/tree/src/servers/app/ServerWindow.cpp#n3585. It comes from the BView through the app_server link, and in the case of BTextView, it is simply set to the current PenLocation(), as seen by the BView.

Notice that the handling of AS_DRAW_STRING for pictures does NOT update the pen location, unlike its direct-drawing counterpart. So, the pen stays at the start of the line and never advances with the text.

A possible fix is to set the current view pen location so that it can be used for further drawing.

[pulkomandy]

This fixes it:

diff --git a/src/kits/interface/View.cpp b/src/kits/interface/View.cpp
index fb7a55f..73f6277 100644
--- a/src/kits/interface/View.cpp
+++ b/src/kits/interface/View.cpp
@@ -3175,6 +3175,14 @@ BView::DrawString(const char* string, int32 length, BPoint location,
 
        _FlushIfNotInTransaction();
 
+       if (fCurrentPicture != NULL)
+       {
+               // The app server does not know how to update the pen location when
+               // drawing to a picture, so do it ourselves.
+               // FIXME handle the escapement deltas
+               MovePenBy(StringWidth(string, length), 0);
+       }
+
        // this modifies our pen location, so we invalidate the flag.
        fState->valid_flags &= ~B_VIEW_PEN_LOCATION_BIT;
 }

Is there a way to do this on app_server side, as is the case for direct drawing? Is there a way to handle the escapement deltas if done there?

[jackburton]

Replying to pulkomandy:

Notice that the handling of AS_DRAW_STRING for pictures does NOT update the pen location, unlike its direct-drawing counterpart. So, the pen stays at the start of the line and never advances with the text.

It actually updates the pen position, as you can see in here: ​http://cgit.haiku-os.org/haiku/tree/src/servers/app/ServerPicture.cpp#n407

Although it explicitly says it does not update the pen position within DrawingEngine/Painter. I seem to recall this worked in the past, so maybe it's a regression after some refactoring. It already happened once (or twice) in this part of the code.

[jackburton]

Replying to jackburton:

Replying to pulkomandy:

Notice that the handling of AS_DRAW_STRING for pictures does NOT update the pen location, unlike its direct-drawing counterpart. So, the pen stays at the start of the line and never advances with the text.

It actually updates the pen position, as you can see in here:

Sorry, now I see what you mean. You're right, from the caller POV, the pen location stays always the same.

[vidrep]

hrev51282 x86_64

Epson NX625 multifunction printer

Tested patch (comment:7) as working.

[vidrep]

Placing the patched libbe.so in /boot/system/non-packaged/lib fixes the issue, but creates a strange terminal output, but only on 64 bit Haiku:

Unlocking BLocker with sem 0 from wrong thread 974, current holder 0 (see issue #6400).

Unlocking BLocker with sem 0 from wrong thread 976, current holder 0 (see issue #6400).

Unlocking BLocker with sem 0 from wrong thread 978, current holder 0 (see issue #6400).

Another aberration created by this patch is print_add-on_server crashing when creating a PDF document with PDFWriter. Debug report attached for such a crash.

[pulkomandy]

We will need debug symbols for the PDF Writer.

[vidrep]

I hope this debug report is what you're looking for

[vidrep]

I built libbe.so on x86_gcc2h and both printing and PDFWriter document creation are working perfectly. The anomalies noted in comment 11 are only seen on 64 bit Haiku, and I have edited that comment to reflect that fact.

[vidrep]

Good news! I tried hrev51352 x86_64 today with the patch and everything is working - printing and PDF document creation. There is no longer an error message in Terminal either. I copied the patched View.cpp from yesterday's x86_gcc2 test, so as to eliminate copy/paste errors (which may have been the issue all along).

I have attached the "working" View.cpp file.

[stippi]

The patch from comment:7 is wrong, though, it should be fixed in app_server.

[pulkomandy]

The patch has been merged as a workaround in the beta1 branch.

It should indeed be fixed on app_server side in master.

[stippi]

Fixed in hrev52716.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone