DrawTextEx not working properly when printing on Windows 98
-
Hi, I have been struggling for some time with a problem experienced by a customer of our product. We have a reporting facility, which allows users to output information to a printer. We have found, on Windows 98, that when a block of text goes over a page, we are losing some text down the gap. To print the text across pages we are using DrawTextEx, and getting the returned uiLengthDrawn to see how much fitted up to the bottom of a page, so we can continue the text from where we left off. This works perfectly on the screen, and also on NT/XP, but the uiLengthDrawn value is always wrong when going to any printer on Windows 98. Has anyone else experienced this problem, and if so, do you know of any solution? Paul. P.S. It's my birthday today! :-D
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV) -- modified at 7:26 Friday 7th October, 2005
-
Hi, I have been struggling for some time with a problem experienced by a customer of our product. We have a reporting facility, which allows users to output information to a printer. We have found, on Windows 98, that when a block of text goes over a page, we are losing some text down the gap. To print the text across pages we are using DrawTextEx, and getting the returned uiLengthDrawn to see how much fitted up to the bottom of a page, so we can continue the text from where we left off. This works perfectly on the screen, and also on NT/XP, but the uiLengthDrawn value is always wrong when going to any printer on Windows 98. Has anyone else experienced this problem, and if so, do you know of any solution? Paul. P.S. It's my birthday today! :-D
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV) -- modified at 7:26 Friday 7th October, 2005
:beer:! Happy Birthday! do you use MFC? If so, maybe you could use
CDC::GetTextExtent(...)to know the size of the text to draw/print? To output text I generally useCDC::TextOut(...)and don't recall having any clipping problem with this method. (the corresponding win32 api are::GetTextExtentPoint32and::TextOut) HTH, K.
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr
-
:beer:! Happy Birthday! do you use MFC? If so, maybe you could use
CDC::GetTextExtent(...)to know the size of the text to draw/print? To output text I generally useCDC::TextOut(...)and don't recall having any clipping problem with this method. (the corresponding win32 api are::GetTextExtentPoint32and::TextOut) HTH, K.
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr
Thanks! :-O Using GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle. Once I've drawn my clipped text onto the bottom of my page, I need to know where in my text string I need to start drawing on the next page. (I do use MFC BTW, but I don't think that's relevant.)
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-
Thanks! :-O Using GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle. Once I've drawn my clipped text onto the bottom of my page, I need to know where in my text string I need to start drawing on the next page. (I do use MFC BTW, but I don't think that's relevant.)
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
Paul S. Vickery wrote: GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle Yes, but not directly. GetTextExtent will give you the size required to draw the given text. Knowing where you begin to write the text, you should then be able to say if the text will go outside a given rectangle or not. IMO? you should use it before drawing. Here's a sample how I use it:
CClientDC dc(this); CFont \*pFont = CFont::FromHandle((HFONT)::GetStockObject(DEFAULT\_GUI\_FONT)); CFont \*pOldFont = dc.SelectObject(pFont); CRect clientRect; CSize textSize = dc.GetTextExtent(sTitle); GetClientRect(&clientRect); int iWidth = clientRect.Width() - 12; // keeping 6 pixels on each side of the text CString strNewTitle(sTitle); while(textSize.cx > iWidth){ // the text is too big to fit: reduce it sTitle = sTitle.Left(sTitle.GetLength() - 1); strNewTitle = sTitle + \_T("..."); textSize = dc.GetTextExtent(strNewTitle); }
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr
-
Paul S. Vickery wrote: GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle Yes, but not directly. GetTextExtent will give you the size required to draw the given text. Knowing where you begin to write the text, you should then be able to say if the text will go outside a given rectangle or not. IMO? you should use it before drawing. Here's a sample how I use it:
CClientDC dc(this); CFont \*pFont = CFont::FromHandle((HFONT)::GetStockObject(DEFAULT\_GUI\_FONT)); CFont \*pOldFont = dc.SelectObject(pFont); CRect clientRect; CSize textSize = dc.GetTextExtent(sTitle); GetClientRect(&clientRect); int iWidth = clientRect.Width() - 12; // keeping 6 pixels on each side of the text CString strNewTitle(sTitle); while(textSize.cx > iWidth){ // the text is too big to fit: reduce it sTitle = sTitle.Left(sTitle.GetLength() - 1); strNewTitle = sTitle + \_T("..."); textSize = dc.GetTextExtent(strNewTitle); }
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr
Mmmm. That's what I was afraid I may have to resort to. It's not very efficient for huge chunks of text, which is why I didn't really want to do it this way in the first place (our reports are often very long, with large chunks of text), but I guess I can optimise it by splitting the string up and testing it using a binary method if it's over a certain length. I guess as it's only a problem on Windows 98, I'll just do it this way for that - maybe that'll teach them to use a real(-ish) OS! Thanks for your time looking at this! Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-
Mmmm. That's what I was afraid I may have to resort to. It's not very efficient for huge chunks of text, which is why I didn't really want to do it this way in the first place (our reports are often very long, with large chunks of text), but I guess I can optimise it by splitting the string up and testing it using a binary method if it's over a certain length. I guess as it's only a problem on Windows 98, I'll just do it this way for that - maybe that'll teach them to use a real(-ish) OS! Thanks for your time looking at this! Paul.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
Yes, it is probably not very efficient, even if is it plausible it can be improved (using dichotomy seems good, making assumption on font width then on likely text length could perhaps also help). Limiting this solution to Win98 users, by detecting the OS, could also limit the damage. Paul S. Vickery wrote: I guess as it's only a problem on Windows 98, Is the problem not occuring on Win95? (I have to deal with this shitty OS, some of our customers still use this big bag of #$ù*#. Also, the problem may come from the implementation of the printer driver on Win9x. Maybe an update of them, with a lot of luck...
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr
-
Thanks! :-O Using GetTextExtent/TextOut is all very well, but that doesn't tell me how much of my text will fit into a given rectangle. Once I've drawn my clipped text onto the bottom of my page, I need to know where in my text string I need to start drawing on the next page. (I do use MFC BTW, but I don't think that's relevant.)
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
There's code in the CEditView class that clips/fits text based on a rectangular boundary. Should be a primary function and a couple of helpers - just copy it to your project, tweak it if need be, and away you go. "When you know you're going to eat crow, it's best to eat it while it's still warm." - Reader's Digest
-
There's code in the CEditView class that clips/fits text based on a rectangular boundary. Should be a primary function and a couple of helpers - just copy it to your project, tweak it if need be, and away you go. "When you know you're going to eat crow, it's best to eat it while it's still warm." - Reader's Digest
Mmm. Just looked at that. It uses a method similar to the one I was avoiding :~ by guessing how many might fit, then decreasing/increasing the length of the string until it fits best. Oh well, looks like that's the way to go. :sigh:
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-
Yes, it is probably not very efficient, even if is it plausible it can be improved (using dichotomy seems good, making assumption on font width then on likely text length could perhaps also help). Limiting this solution to Win98 users, by detecting the OS, could also limit the damage. Paul S. Vickery wrote: I guess as it's only a problem on Windows 98, Is the problem not occuring on Win95? (I have to deal with this shitty OS, some of our customers still use this big bag of #$ù*#. Also, the problem may come from the implementation of the printer driver on Win9x. Maybe an update of them, with a lot of luck...
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr
Just looked at source for CEditView printing, as suggested by Jack Squirrel in his reply[^], and it seems that MFC uses a similar method, by having a guess, and then adjusting the string until it best fits. They do that for all platforms (MFC doesn't use DrawTextEx anywhere as MFC pre-dates the function). Looks like that's what I'm going to have to do after all :sigh: , but at least our customer will be happy! :)
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV) -- modified at 5:05 Monday 10th October, 2005
-
Just looked at source for CEditView printing, as suggested by Jack Squirrel in his reply[^], and it seems that MFC uses a similar method, by having a guess, and then adjusting the string until it best fits. They do that for all platforms (MFC doesn't use DrawTextEx anywhere as MFC pre-dates the function). Looks like that's what I'm going to have to do after all :sigh: , but at least our customer will be happy! :)
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV) -- modified at 5:05 Monday 10th October, 2005
Yep, avoiding DrawTextEx seems the good thing to do, jack's advice is the good one. I just have a look to CEditView printing too, very interesting. I learned something, there is an undocumented fucntion _AfxClipLine which may be useful sometimes. Thanks for the feedback! :)
The great error of nearly all studies of war has been to consider war as an episode in foreign policies, when it is an act of interior politics - Simone Weil Fold with us! ¤ flickr