Which "entity" is working at more deeper level than Characters of a program?

Question

It is commonly told that, while we write a program, we input with our language (A, B, C, D etc), whom computer translates into machine language into machine language made up of Zero (0) or switch off and One (1) or switch on, a.k.a. ASCII code.

Letter ... ASCII Code .... Binary

A ........... 065 ............ 01000001

B ........... 066 ............ 01000010

But I don't think it is that simple.

When I type A on the keyboard, the programming prompt (say C-programing) screen shows me a letter A or a (depending upon caps lock or not) that have a definite geometric shape and orientation. There are other factors, like which part on screen the letter will be shown.

Even if A=01000001 I don't think just turning off 6 pixels (Six ZEROS) and turning on 2 pixels (two ONES) it is possible to render triangular capital-letter A.

Now my question is; What is the "Entity" (maybe a software) which is rendering a small 0-1 code into a geometric figure (glyph)? Such as 01000001 into a triangular shape (A) or rendering 01000010 into a vertical line with two bulge at right hand side (B) etc.

Answer 1

There are many pieces of software involved in rendering an "A" when you type it in to a program like a text editor.

• First, the key press is handled by the hardware of the keyboard, which sends a signal to the OS's keyboard driver. This is where stuff like the state of the shift key and caps lock get noted (though the information about which modifier keys are pressed will usually just be passed along with the information about the key pressed, rather than "a" turning into "A" just yet).

• The key press information next gets passed to the window manager (which is usually part of the OS), to determine which program has "keyboard focus" at the moment. If nothing has focus, the window manager might discard the key press here (though it might also intercept other presses, like ALT+Tab).

• Next the active program likely gets a key-press event. Often the program's event processing happens in a library provided by the window system, though what it will do with the events after they happen is up to the application itself.

• An editor program will likely interpret a key press like "A" as input for a file you have open. It will add the character to its memory buffer representing the file's contents. This may be the first place where the ASCII representation for "A" becomes relevant, as keyboards and windowing systems often use their own codes for key presses. (Note though that a modern editor will probably use some encoding of Unicode, rather than ASCII to represent text. This adds some extra complication, but makes it possible to handle text in any language, not only English.)

• Now the program has to draw the "A" to the screen. First it will probably have to do a bunch of calculations to determine how it wants to lay out all its text. Many editors wrap long lines of text, for instance, which can be pretty complicated to get right.

• Once the program has decided exactly where on the screen it wants to put each part of its text, it will render them using a font. The font describes what each glyph should look like (this is also very complicated). The font render (which is often part of a library provided by the OS or window manager, though an application can do its own rendering if it really wants to) transforms the "A" to a specific set of pixels.

• Next, the pixels for the "A" (along with those for the other text, and the rest of the editor's UI) get sent to the graphics driver. Other programs may also be sending their own pixels if other windows are visible alongside the editor. The window manager will usually also have some parts of the screen that it manages itself (like the taskbar, but sometimes also the borders of the windows).

• The graphics driver sends on all the data to the hardware graphics card in the machine. Some PCs these days (especially laptops) don't have a dedicated graphics card, but they'll have a chip on the motherboard that does essentially the same thing. The graphics card will assemble all the graphics into a buffer representing all the pixels of the screen. It will send the contents of that buffer to the monitor every time it needs to redraw the screen (usually 60 times per second, though other refresh rates are becoming more common).

The steps above are intended to be fairly general. Typing a key into a specific program on your computer may not have exactly the steps I describe (it could have more or fewer). For instance, if your editor is a console application rather than a graphical one, you may not have any window manager involved, and very basic fixed-width font rendering might be done directly by the hardware of the graphics card.

The exact boundaries between some of the layers may also be hard to distinguish in some cases, especially when the application is using libraries provided by the OS, window manager or graphics driver for some of the steps (like the event loop and font rendering).