Opened 8 years ago

Closed 3 months ago

#6761 closed bug (fixed)

Wrong positioning printing line of words in different colors

Reported by: laplace Owned by: korli
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by 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)

Attachments (7)

TestPage.zip (2.8 KB) - added by laplace 8 years ago.
test (4.5 KB) - added by jackburton 4 years ago.
print_addon_server-865-debug-01-08-2017-00-27-30.report (21.6 KB) - added by vidrep 20 months ago.
print_addon_server-6186-debug-01-08-2017-17-00-54.report (28.1 KB) - added by vidrep 20 months ago.
View.cpp (140.1 KB) - added by vidrep 20 months ago.
PDF_test (1.4 KB) - added by vidrep 20 months ago.
Print_test.png (90.0 KB) - added by vidrep 20 months ago.

Download all attachments as: .zip

Change History (27)

Changed 8 years ago by laplace

Attachment: TestPage.zip added

comment:1 Changed 8 years ago by laplace

Description: modified (diff)

comment:2 Changed 4 years ago by 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?

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by jackburton

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

Changed 4 years ago by jackburton

Attachment: test added

comment:5 Changed 3 years ago by vidrep

hrev50006 x86_gcc2 Printer: Epson NX625

I am still able to reproduce this problem

comment:6 Changed 2 years ago by pulkomandy

Component: Applications/StyledEditServers/app_server

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.

comment:7 Changed 2 years ago by 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?

comment:8 in reply to:  6 ; Changed 2 years ago by 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.

comment:9 in reply to:  8 Changed 2 years ago by 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.

comment:10 Changed 20 months ago by vidrep

hrev51282 x86_64

Epson NX625 multifunction printer

Tested patch (comment:7) as working.

comment:11 Changed 20 months ago by 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. Again, this is only a 64 bit Haiku issue. Debug report attached for such a crash.

Last edited 20 months ago by vidrep (previous) (diff)

comment:12 Changed 20 months ago by vidrep

Has a Patch: set

comment:13 Changed 20 months ago by pulkomandy

We will need debug symbols for the PDF Writer.

comment:14 Changed 20 months ago by vidrep

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

comment:15 Changed 20 months ago by 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.

comment:16 Changed 20 months ago by 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.

Changed 20 months ago by vidrep

Attachment: View.cpp added

Changed 20 months ago by vidrep

Attachment: PDF_test added

Changed 20 months ago by vidrep

Attachment: Print_test.png added

comment:17 Changed 14 months ago by pulkomandy

Has a Patch: unset

comment:18 Changed 7 months ago by stippi

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

comment:19 Changed 7 months ago by pulkomandy

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

It should indeed be fixed on app_server side in master.

comment:20 Changed 3 months ago by stippi

Resolution: fixed
Status: newclosed

Fixed in hrev52716.

Note: See TracTickets for help on using tickets.