Solved

Own font printing

Posted on 1998-11-24
18
233 Views
Last Modified: 2013-12-03
I have got my own TT font with some symbols and there is a problem with printing some characters on printer in Windows NT. Codes of this characters are 131, 136, 140, 141, ...
On screen this characters are shown right. In LOGFONT is lfCharSet set on SYMBOL_CHARSET.
0
Comment
Question by:knill
  • 8
  • 6
  • 4
18 Comments
 

Author Comment

by:knill
ID: 1416290
Edited text of question
0
 
LVL 22

Expert Comment

by:nietod
ID: 1416291
It sounds like you are printing with a different font than you are using to draw to the screen.  That is the only possible explanation, I can think of. Can you post the code you use to fill in the LOGFONTs and to create the two fonts?
0
 

Author Comment

by:knill
ID: 1416292
No, I use the same font for draw and printing.
The font is initialized in the constructor of a child of CSrollView.

LOGFONT logFont;
memset((void*)&logFont, 0, sizeof(LOGFONT));
logFont.lfWeight = FW_NORMAL;
logFont.lfQuality = PROOF_QUALITY;
logFont.lfHeight = 25;
logFont.lfCharSet = SYMBOL_CHARSET;
strcpy(logFont.lfFaceName, "Railways");
m_Context.symbols[0].CreateFontIndirect(&logFont);


This code is colled during drawind and printing.
SymbolStruct symbols[] = {
8260,510,130,0,RGB(128,64,0),
8260,580,131,0,RGB(128,64,0),
8260,615,132,0,RGB(128,64,0),
8260,650,133,0,RGB(128,64,0),
8260,690,134,0,RGB(128,64,0)};
for (i = 0; i < 5; i++)
{
pDC->SetTextColor(symbols[i].color);
pDC->SelectObject(&m_Context.symbols[symbols[i].font]);
CString str(symbols[i].symbol);
pDC->TextOut(symbols[i].x, -symbols[i].y, str);
}

Maybe a problem is in my font. I created this one in Corel Draw.
0
 
LVL 22

Expert Comment

by:nietod
ID: 1416293
what is the problem that you see on the printer?  Do any characters of the font print okay on the printer?  What is the mapping mode of the printer DC?  If it is text and if this is a laser or ink jet printer, then a 25 unit high font will be tiny.
0
 

Author Comment

by:knill
ID: 1416294
The problem is, that some characters are printed right and others not. Instead of some chracters is printed one character which is on undefined codes in the font. What more. When I run the program in Windows 95, and print the same, everything is right.
Mapping mode is MM_LOMETRIC.
0
 
LVL 22

Expert Comment

by:nietod
ID: 1416295
So it works under 95 and not NT.  Hadn't caught that before.  There are differences in font mapping between the two.  Are you sure that on NT it is using the font you thought?  If you use GetObject() on the font and look at the font name, is it the font you thought it would be?
0
 
LVL 22

Expert Comment

by:nietod
ID: 1416296
Did you define multiple sizes/styles of the font?  Are these characters defined in all the sizes/styles?
0
 

Author Comment

by:knill
ID: 1416297
Yes, on NT it is using that font, because in the font there are character, which aren't in any other font. And these characters are printed and drawen right. The otheres not.
0
 

Author Comment

by:knill
ID: 1416298
It's an ordinary scalable true type font of symbols with one style of characters and I don't use other than normal weigth.
Do you want to see this font?
0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 
LVL 22

Expert Comment

by:nietod
ID: 1416299
No, if you only have one that doesn't explain it.  I'm at a loss.  Perhaps it has something to do with unicode?  I don't know.
0
 

Author Comment

by:knill
ID: 1416300
Adjusted points to 150
0
 
LVL 27

Expert Comment

by:BigRat
ID: 1416301
The characters which don't come out wouldn't be the last n would they?
It might be the fact that the fsLastCharacter index in the true type parameters is not correctly set, so no bitmap will be built up. It just may be that Windows-NT or the Printer driver is somehow sensitive to such things.
   I would suggest that you try to get hold of Fontographer from Altsys Corp. or something similar and check that the font produced by Corel has all the parameter set correctly
0
 

Author Comment

by:knill
ID: 1416302
No, some are printable and some aren't. For example all characters with code to 126 and 130,132,..,135,145,164,206,235 are printable and characters with code 127,..,129,131,144,152,200,234,... aren't.
0
 
LVL 27

Expert Comment

by:BigRat
ID: 1416303
How very strange indeed! It must be the curves that Corel has produced. A daft question might be "have you used the Font in Word? And have you successfully printed from Word?" However I can imagine that you have and get the same result.
   Might I ask if I could try out your font? My address is BigRat@t-online.de
0
 
LVL 22

Expert Comment

by:nietod
ID: 1416304
Since A) the font works in windows 95 and B) TT fonts only support one type of curve (which I'm sure Corel produces correctly.  It is a high quality precission drawing tool far superior to Fontographer etc.) I don't think the problem is in Corel.  I suspect the problem lies in how windows NT is mapping these Non-ASCII characters.values to cells in the font.  NT supports unicode and code pages and lots of stuff that has to do with this.  I'm not familair with that stuff, but I suspect the problem lies there.
0
 
LVL 27

Expert Comment

by:BigRat
ID: 1416305
Thank you, I have received your font and checked out the TrueType parameters and the characters which don't print. It all seems OK.
   I have been through the WinNT DDK documentation, The Unicode standard and the various code page tables and have come up with a senario which can fit the symptoms of the fault.
   The device driver on WinNT wants a Unicode input, receives however Windows-ANSI. It therefore converts the Windows-ANSI to Unicode and the following happens. First the unallocated characters in the ANSI character set which appear in the input are replaced by spaces or underlines (You do not say which characters are printed instead of yours, so I'm not quite sure which). Secondly the characters which ARE allocated in the ANSI character set are translated OUT of your font and consequently are also not printed. This occurs with characters 200 and 234 (hex C8 and EA) which, in ANSI code page 1250 (Windows Central Europe), are capital C with caron and small e with ogonek (Unicode 010C and 0119 resp.). If you had been using ANSI code page 1252 (Windows Latin 1) these two characters translate to the SAME Unicode values, only the character 131 (Hex 83 small florin f) gets translated out (to 0192). All the characters which you say print correctly translate to their Unicode equivalents from code page 1250 to the SAME values.
   I shall confirm this on Monday at work, since we have various NT systems with printers and I can test various code pages. The solution appears to me, to be to re-map the font, so that the characters used translate to the same values in Unicode as in the code page you use (1250 it seems) and if you want to export your program to the rest of Europe also ensure that the same values are used in 1252.

0
 
LVL 27

Accepted Solution

by:
BigRat earned 150 total points
ID: 1416306
So I have now tested your font on 95 and through NT 4.0 and on 4.0. Naturally printing from 95 is OK. Interesting printing from 95 on a printer attached to NT produces identical results. But printing on NT causes loss of characters.
   I have also noticed that you font is Symbol character set. This means that the characters above hex 80 are mapped to Unicode hex F0xx, so the situation is worse than I thought. I advise you to move all characters above hex 80 to between hex 20 and hex 7F. Not all positions below 7F are used and as far as I can see it is possible to move them all. It will mean that you may have to change your program.
   Finally I like the font. The symbols included in it are for railway time-tables. May I suggest that you propose adding some of the symbols to the Unicode standard? You can get info from http://www.unicode.org. Some of your symbols are amongst the Dingbats but a lot are not (Sleeping car, restaurant car, Work Days, etc..).
   For more ionformation reject this answer.

0
 

Author Comment

by:knill
ID: 1416307
Thank you for your advise.
We didn't think about proposing symbols from this font to the Unicode standard, but this font isn't protected by any copyright. So if you want...
0

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Suggested Solutions

This article surveys and compares options for encoding and decoding base64 data.  It includes source code in C++ as well as examples of how to use standard Windows API functions for these tasks. We'll look at the algorithms — how encoding and decodi…
For most people, the WrapPanel seems like a magic when they switch from WinForms to WPF. Most of us will think that the code that is used to write a control like that would be difficult. However, most of the work is done by the WPF engine, and the W…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…

746 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now