Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65810

Re: Character display

Show all headers | View raw

David Kleinecke <dkleinecke@gmail.com> writes:
> I have been thinking about the ideal way to handle text data in C. The 
> point of departure is my disapproval of section 5.2.2 of the C90 
> Standard (repeated in all later Standards). I am not arguing for
> changes in C (outside of 5.2.2) but rather how to accommodate what 
> I feel is ideal in Standard Freestanding C90.

Though the standard doesn't say so explicitly (perhaps it should),
section 5.2.2, "Character display semantics", does not (necessarily)
apply to freestanding implementations.

It talks about the behavior of fputc, which is not required for
freestanding implementations.

See N1570 4p6 (or, if you insist, the second paragraph of
section 4 of C90) for the definitions of hosted and freestanding
implementations.

> It is possible to think of a digital text not as an array of 
> characters but rather as an array of indices of glyphs (that would be 
> used to display the text).

I'm not sure I understand this.  Are you saying that the value of the
character 'A', for example (which might be 65) is an index into an
array, where the value of the array element represents the glyph (the
image that's drawn when the character is displayed)?

I think that's outside the scope of what should be in the C standard.
For example, sending the code 65 to an output device might cause a
particular hammer to strike the paper, or a print ball to rotate to a
particular position.

Even if there is a mapping from character codes to glyphs, who says it's
an array?  (There are various representations for fonts; I don't know
the details.)

The character is printed.  I don't think the C standard should concern
itself with how that's done.

>                            This idea can be generalized to an array of 
> actions - drawing a glyph, pronouncing a sound or even sounding a 
> musical chord. Under such an assumption most of stdio is a special 
> case of what might be done rather than anything a standard should
> concern itself with (but of course, by declaring my interest to be 
> free-standing I need not worry about stdio).
>
> But this, essentially, leaves character constants and string literals
> meaningless.

Character constants denote numeric values.  String literals denote
arrays of integer values terminated by a 0.  The semantics of *printing*
characters is described (with IMHO appropriate vagueness) in 5.2.2.

I might argue that the semantics of the control characters are
over-specified.  For example, printing a '\f' character commonly
*doesn't* move the active position to the initial position at the start
of the next logical page.  But the standard says they are *intended* to
produce such actions, which I suppose is enough of an escape hatch.

>              If I assume there is a map from what legally can appear 
> between two single quotes to an index (as there obviously is in the 
> standard case) then I can say the value of '...' is the index of 
> source code "word" between the quotes. But I don't want to give 
> these "words" identifier status. So I assume there is a global array 
> somewhere that contains this map as a set of pairs. (In standard C 
> this map is simplified to an array because the indices are compact - 
> but the general case can make no such assumption.)   

I don't think describing characters as indices into some hypothetical
array is helpful.

> Then "..." means a sequence of "words" that might appear as character 
> constants. I would separate these words by the same rule the pre-
> processor uses - the longest possible word. (This is almost automatic 
> in Standard C because a "word" usually is a character but escape-
> sequences are easily handled.)  I assume the final "word" remains 
> the null character.
>
> In many cases I will need no more than 8-bits worth of indices but 
> all that I assume is that all indices are the same size. That gives 
> internal text a clear shape - a sequence of non-null indices 
> terminating in the null index. Then I must supply functions 
> "int display_a (test* t) {...}" etc. for different kinds of displays 
> I may want to do. I will, of course, also need at least one input 
> program.  

I'm not clear on the context in which you feel all this is needed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 12:51 -0700
  Re: Character display James Kuyper <jameskuyper@verizon.net> - 2015-07-17 16:20 -0400
    Re: Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 18:57 -0700
      Re: Character display James Kuyper <jameskuyper@verizon.net> - 2015-07-17 23:22 -0400
      Re: Character display Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 10:18 -0700
  Re: Character display Keith Thompson <kst-u@mib.org> - 2015-07-17 13:44 -0700
    Re: Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-17 19:06 -0700
      Re: Character display Keith Thompson <kst-u@mib.org> - 2015-07-17 21:33 -0700
      Re: Character display Geoff <geoff@invalid.invalid> - 2015-07-18 00:33 -0700
        Re: Character display Geoff <geoff@invalid.invalid> - 2015-07-18 10:09 -0700
        Re: Character display James Kuyper <jameskuyper@verizon.net> - 2015-07-18 13:45 -0400
        Re: Character display David Kleinecke <dkleinecke@gmail.com> - 2015-07-18 18:51 -0700
          Re: Character display Keith Thompson <kst-u@mib.org> - 2015-07-18 21:08 -0700
            Re: Character display Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 00:33 -0700
              Re: Character display Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 17:03 -0500

csiph-web