Re: Problem in char " ® "



sweety wrote:
The charecter/symbol " ® " writen in a file able to get only in that
system. When the file opened in other system, not able to see that
charecter, insted its viewd as " ? ". So, the special char sets are
different system to system?

From what I can understand from the vague posts of yours in this
thread, it sounds like you're using a source control system and on one
(Windows) computer, when you edit a file in a text editor, it shows up
as (R), but on another computer it shows up as ?. If this is the case,
this is completely irrelevant to C or this newsgroup but I will help
you out anyway. Depending on how lazy the programmer of your text
editor was, there are a few different options:

- Set the encoding when saving the file, make this match up with the
destination.
- Set the encoding when reading the file, make this match up with the
source.
- If neither of the above are available then you have to set the
codepages to both computers to be the same (control panel | regional
options | general tab | set default).
- If even the above doesn't work, then the programmer of both text
editors went out of their way to be extremely evil. In which case, use
a better text editor.


Also, it might be a font issue because if one computer is editing using
a unicode font like "Courier New" and the other computer is using an
old font like "Terminal" which hardcodes the glyphs independent of what
your codepage is set to (and this font in particular doesn't even have
the (R) glyph). If you're on a non-Windows 9x computer, you can check
this out by going to Programs | Accessories | System Tools | Character
Map and seeing if the source and destination fonts are the same. I
doubt this is the case because by default, the ? character is used as a
substitution for encodings that don't map, and this would only come up
if the codepage doesn't map properly but it's something to be aware of.

How can over come this problem , that to view this symbol " ® " using
the same kind of editor in any system.

You can't.

For close to 100% portability, stick with the charset that the C
standard guarantees is available. For pretty good portability stick to
ASCII. Both of these solutions requires you to use "(R)" sequence
instead of the glyph you're trying to encode. International newsfeeds
like Reuters use this option because it works extremely well.

If you *really* want to use the (R) glyph, people that don't care about
international text usually use one of the latin-1 like encodings (the
Windows-1252 codepage is mostly abused for this purpose because most
people are ignorant of the issue) but if you want to be a good citizen
use UTF-8.

.



Relevant Pages

  • Re: GDI does not provide all GLYPH handles for big font size
    ... By the way, if the font gets even bigger, DrvTextOutis no ... MoreGlyphs = FALSE; ... // will do a STROBJ_bEnum first, in order to load up the Glyph data. ... int x, y; ...
    (microsoft.public.development.device.drivers)
  • Re: extract text from PDF file
    ... Ken> the glyphname has a matching ASCII character. ... In an attempt to obfuscate a PDF file, I have tried reencoding a font. ... It must be the glyph ...
    (comp.lang.postscript)
  • Re: extract text from PDF file
    ... Ken> reliable method is to OCR the document. ... e.g. the glyph metrics may already be ... I don't think there's anything that will deal with a PDF file, extract ... the font outlines and use those, no, but I could be wrong. ...
    (comp.lang.postscript)
  • Re: digging rules
    ... David Alex Lamb wrote: ... Unfortunately my WinXP doesn't have something to open .ASC files. ... Your editor may import ... The DOS font included 128 high bit characters which are ...
    (rec.games.frp.dnd)
  • Re: Missing characters/unusable font in Word 2004
    ... character number of a glyph is by its position in the table. ... very small font that contains few glyphs, so several of those positions are ... we're only interested in its Unicode value. ...
    (microsoft.public.mac.office.word)