I need help - I can help - Non-breaking spaces in DrawText not displayed

Print Page | Close Window

Non-breaking spaces in DrawText not displayed

Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: I need help - I can help
Forum Description: Problems and solutions while programming with the Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=2185
Printed Date: 29 Apr 25 at 11:37AM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com

Topic: Non-breaking spaces in DrawText not displayed

Posted By: bozzy
Subject: Non-breaking spaces in DrawText not displayed
Date Posted: 09 Mar 12 at 11:52AM

Hi.

I'm having a similar problem to that exposed here:

http://www.quickpdf.org/forum/spaces-in-drawtextbox-not-displayed-in-pdf_topic1288.html - http://www.quickpdf.org/forum/spaces-in-drawtextbox-not-displayed-in-pdf_topic1288.html

In order to maintain spaces between words when using DrawTextBox, I've created a function that substitutes Chr(32) with Chr(160). I call this function whenever I have to put out text on a PDF, regardless of whether I'm going to use DrawText or DrawTextBox.

The problem is that, quite surprisingly to me, DrawText is "eating" non-breaking spaces Chr(160), behaving exactly the opposite than DrawTextBox.

Is this another "feature" or is it a bug?

Thanks,

Bozzy

Replies:

Posted By: AndrewC
Date Posted: 12 Mar 12 at 1:00PM

Can you post a quick example to show the problem so that I know that we are talking about the same problem. DrawText and DrawTextBox are two different routines but it should be quite possible to make them work the same way in regards to Chr(160).

Posting a quick example will make sure we fix the exact problem.

Andrew.

Posted By: bozzy
Date Posted: 12 Mar 12 at 3:26PM

I've just found that something's changed from QuickPDF 7.xx to QuickPDF 8.xx in regards to Chr(160).
It took me some time to figure it out, because I was SURE that DrawTextBox would "eat" multiple-spaces - Chr(32) - in v7.xx, while now it doesn't anymore.

Now it seems that DrawText and DrawTextBox behave exactly the same, so they keep sequences of Chr(32) intact and completely "eat" sequences of Chr(160).

This could be fine for me, but at this point I'm asking that things remain stable in the future, 'cause a year ago I've had to rewrite a lot of functions using DrawTextBox in order to put Chr(160) to maintain text formattation, and now, more by coincidence than other, I've found that I have to rewrite them again in order to restore standard space Chr(32) in place of non-breaking space Chr(160).
Better would be if also Chr(160) would be printed as a space, so I can let the functions as they're now.

This is a code snippet in Delphi to reproduce the problem (missing #160 spaces in PDF).

procedure TForm1.Button1Click(Sender: TObject);
begin
with TQuickPDF.Create do
try
    UnlockKey(********);
    SetPageDimensions(842, 595);
    SelectFont(AddStandardFont(0));
    SetTextSize(12);
    DrawText(20,550,'HELLO' + #160#160#160#160#160 + 'WORLD    by    DrawText!!!');
    DrawTextBox(20,530,800,20,'HELLO' + #160#160#160#160#160 + 'WORLD    by    DrawTextBox!!!',1);
    SaveToFile('c:\test.pdf');
finally
    Free;
end;
end;

Thank you.

Bozzy

P.S. if you'd like to see the PDF created with QuickPDF v7 and v8 let me know where to attach files.

Posted By: bozzy
Date Posted: 12 Mar 12 at 3:37PM

Just to be complete, watching at the thread I've mentioned in my first post above, there's a post by Rowan who says:

Ingo is right, it's by design.

The DrawTextBox function splits the text into words to do the wrapping and when it puts the words back together again it just adds a single space. Using Chr(160) should fix the problem as it is a non-breaking space. For the DrawHTMLText function the   entity can be used.

Cheers,

- Rowan.

Now it's behaving differently and it seems this isn't explained in any release notes or in the manual. If you'll decide to keep Chr(160) as non-printable, maybe it's worth spending two words in the manual and maybe adding a comment in the original thread about DrawTextBox and Chr(32) / Chr(160) difference.

Cheers.

Bozzy

Posted By: bozzy
Date Posted: 23 Mar 12 at 11:20AM

Hi.

Any news here? Can I go and replace Chr(160) with Chr(32) when using the DrawTextBox and DrawText functions? Will it stay as it's behaving now?

Cheers,

Bozzy

Posted By: Rowan
Date Posted: 29 Aug 13 at 2:54AM

Hi Bozzy,

I have tested using Chr(160) and Chr(32) in version 9.16 Beta 2 with DrawText and DrawTextBox and they are both working as expected. Though it is possible that certain fonts won't support char 32 and 160. You can download 9.16 Beta 2 from here:

http://www.debenu.com/blog/debenu-quick-pdf-library-9-16-beta-2.html" rel="nofollow - http://www.debenu.com/blog/debenu-quick-pdf-library-9-16-beta-2.html

Can you try again using 9.16 beta 2 and let us know how you go? If it still doesn't work on your end please post the code you're using and the PDF that is generated on your end.

Cheers,

- Rowan.