Own font printing

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.
knillAsked:
Who is Participating?
 
BigRatConnect With a Mentor Commented:
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
 
knillAuthor Commented:
Edited text of question
0
 
nietodCommented:
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
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

 
knillAuthor Commented:
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
 
nietodCommented:
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
 
knillAuthor Commented:
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
 
nietodCommented:
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
 
nietodCommented:
Did you define multiple sizes/styles of the font?  Are these characters defined in all the sizes/styles?
0
 
knillAuthor Commented:
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
 
knillAuthor Commented:
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
 
nietodCommented:
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
 
knillAuthor Commented:
Adjusted points to 150
0
 
BigRatCommented:
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
 
knillAuthor Commented:
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
 
BigRatCommented:
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
 
nietodCommented:
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
 
BigRatCommented:
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
 
knillAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.