How to display an image using c? - c

I want to display an image using c in linux platform.And now i have read the image file ( gif)into an array of char. But I don't know what to do next to display it? Can anybody help me?

This is a quite complicated question since you're not being very specific.
C in itself doesn't have a concept of an "image" or even a "display". You need to mix in some environment-specific details that add such concepts, for instance you could work with the Framebuffer in (console) Linux, the X11 window environment, GNOME/GTK+, KDE or perhaps Enlightenment.
All of these give radically different answers.

You need a graphic toolkit to do that. Plain old C language is not enough.
You can try these toolkits:
QT
GTK
There are many others that will also do what you want, but these two are among the most populars I guess.

Related

Is there an user-level accessible font table present in Linux?

Since there is this: http://en.wikipedia.org/wiki/Code_page_437 For MSDOS, is there something similar for Linux systems? Is it possible to access that font data via userland program? I would actually just need an access to the actual bit patterns which define the font, and I would do the rendering myself. I'm fairly sure that something like this exists, but I haven't been able to find what exactly is it and how to access it. After all, e.g. text mode console font has to reside somewhere, and I really do hope it is "rawly" accessible somehow for a userland program.
Before I forget, I'm programming my program in C, and have access only to the "standard" linux/posix development headers. The only thing I could came up with myself is to use the fonts in /usr/share/fonts, but having to write my own implementations to extract the data from there doesn't sound really an option; I would really want to achieve this with the least amount of bytes possible, so I feel I'm left with finding a standard way of doing this.
It's not really feasible for me to store my own 8x8 ASCII-compatible font with the program either(it takes some 1024 bytes(128 chars * 8x8 bits) just to store the font, which is definitely unacceptable for the strict size limits(some < 1024 bytes for code+data) which I am working with), so being able to use the font data stored at the system itself would greatly simplify my task.
I had a look at consolechars sources and it looks like there is a whole library for this kind of stuff. On Ubuntu it's named libconsole and header files (like lct/font.h) are in the console-tools-dev package. There are functions to find and load fonts which seems to be exactly what you need. And consolechars source is a nice example of how to use them.
You should use freetype , its commonly installed in all the Linuxes.

Display pixel on screen in C

How would I change a pixel on a display, in C?
Assume NOTHING: I am using a linux machine from console to do this. I do not want to use GUI toolkits or frameworks to draw the pixel. I do not want to draw the pixel in a window. I want to draw the pixel directly to the screen.
EDIT: I have a screen. I'm on a laptop running linux from console. I'd prefer a solution not using X as I'd rather learn how X works than how to use X.
If theres more information, ask, but don't assume. I'm not trying to build a GUI, and that was the main purpose of blocking assumptions as I don't want people to assume I'm doing things the long way when in reality I'm just tinkering.
EDIT 2: You may use any X11 related libraries provided that you can explain how they work.
If we really assume nothing, can we even assume that X is running? For that matter, can we even assume that there is a video card? Perhaps Linux is running headless and we're accessing it over a serial console.
If we are allowed to assume a few things, let's assume that Linux has booted with framebuffer support. (It's been a couple years since I worked with Linux framebuffers, I may get some of the details wrong.) There will be a device created, probably /dev/fb or /dev/fb0. Open that file and start writing RGB values at an offset, and the screen will change, pretty much regardless of anything: text console, graphical console, full-fledged desktop envrionment, etc. If you want to see if framebuffer support is working, do dd if=/dev/zero of=/dev/fb on the command line, and the display should go all black.
C doesnt have any graphics capabilities - you'd need to use a third party library for this.
You cannot assume a display in C. There is literally no way to do what you ask.
Edit: Okay, you have a display, but again, there's not a whole lot you can get from there. The point is that there are a TON of competing standards for graphics displays, and while some of them (VGA interfaces, for example) are standardized, a lot of the others (display driver interfaces, for example) are NOT. Much of what X (and other display device drivers, such as Windows or the like) do, is have specific interface code for how to talk to the display drivers; they abstract out the complexity of dealing with the display drivers. The windowing systems, though, have HUGE libraries of complicated and specific code for dealing with the display drivers; the fact that these things are relatively transparent is an indication of just how much work they've put into these things over time.
Very primitive and making a lot of assumptions:
fd = open("/dev/fb0", O_RDWR);
lseek(fd, 640*y+x, SEEK_SET);
write(fd, "\377\377\377\377", 4);
In reality, you would use mmap rather than write, and use the appropriate ioctl to query the screen mode rather than assuming 640xHHH 32bpp. There are also endian issues, etc.
So in real reality, you might use some sort of library code that handles this kind of thing for you.
I suppose you could paint to the terminal program that you are using as your console. All you have to do is figure out which one that is and look it up.
Whoops I assumed a terminal. :P
I think what you are looking for is information on how to write to the frame buffer. The easiest way would be to use SDL and render to the frame buffer, or else use GTK+ with DirectFB, although that goes against your edict on not using toolkits or frameworks.

TrueType Font Parsing in C

I want to read a ttf and draw a text with that font on a buffer. Even though there are libraries such as freetype, gd to do this task, I want to write my own code. Can you advice me on how to accomplish this task?
Unless you're one of the world's top experts on fonts, typography, and writing systems, the answer is simple: DON'T. TrueType/OpenType has a lot of tables you need to support for correct rendering, and even when using FreeType (which is an extremely low-level library), most people get it wrong.
If you need to do low-level, deterministic-across-platforms font handling, then at the very least, you should be using FreeType and libotf. This will provide you with access to the glyphs and outlines which you can then render however you like. In most cases though using your GUI system's text rendering routines will be a lot easier and less error-prone.
Finally, if you insist on ignoring my advice, a good RTFS on FreeType and Microsoft's online resources explaining the tables in TrueType/OpenType fonts are probably the best place to get started.
I would suggest you
Read all the TTF docs you can find
Find all the open source TTF parsers + renderers you can find, in many different languages, such as Freetype (c/c++), Batik (java), and anything else you can google for. Also George Williams' fontforge will likely be very helpful to you on your journey.
Rip apart all the programs you collected in 1. and see how they work. See if you can make a tiny small example program to do something simple, like dump the list of points for the outline of the letter "I".
Work on your rasterization. Start with something very simple, like rasterizing the letter "l".
The problem with TTF is that there is not a simple file format, and freetype handles a lot of crazy details for you. However if you don't care about portability, and you already have a specific TTF file you want to render, and you only care about a small simple alphabet, like Latin or Cyrillic, you might be OK.
Also you might want to check out a list of TTF documentation I linked to from my little project https://github.com/donbright/font_to_svg/
Not impossible, for anyone else tempted to try. I was curious about doing it because I like the DIY graphics approach where I allocate some memory and write into it, then save as a jpg or png. I pirated a bitmap font from giflib but that's strictly 8x8 pixels.
A few links:
`http://stevehanov.ca/blog/index.php?id=143`
`https://www.google.com/search?q=ttf+parser+c&ie=utf-8&oe=utf-8`
as R.. wrote the same time as i did in my comment, i would not to suggest to build another TTF-parser by your own. If you are eager to learn this very "spannende" field of Computer Science I would recommend "The Art of Computer Programming" Vol 2 from Donald E. Knuth. (it is Metafont, not TTF, but proven to be correct:-)

C code for loading bitmap

Does anybody know a good C sample that loads bitmaps and handles all the cases: rle, b/w bitmaps, so on?
Code should be cross-platform.
Thanks.
I would suggest using a library like SDL image
If you are looking for a minimal bmp loader this link will give you all you need to know about the BMP format, data structures and sample code without any library dependency to load:
http://paulbourke.net/dataformats/bmp/.
It also contains code to see the loaded BMP in a open gl texture, so pretty much all you need...
Chris Backhouse made a functional little BMP loader (with an eye to using them as OpenGL textures). It's C++, not C, and he admits it's not cross platform. However, it's small and easy to understand, so I thought I'd add the link here:
http://users.ox.ac.uk/~orie1330/bmploader.html
You need some external library to do this (I recommend ImageMagick). The ImageMagick web site also includes documentation and examples.
Check out for OpenCV Library developed by Intel .
If you are tied to the BMP file format, it's pretty simple to look at the header yourself and get the pixels. See this google search. One of the more interesting matches is here. The most counter-intuitive part is that every line of pixels is 4-byte aligned. Also, watch out for compressed BMPs... (My experience is that many third-party tools have trouble with compressed BMPs, so maybe some libraries you encounter will also..)
If you aren't tied to the BMP file format, I recommend libpng. The manual provides some sample code which is pretty clear.
As others suggested you might want to use an external library like SDL. If you want to learn something and do it yourself, see my answer to this very similar question: Getting RGB values for each pixel from a 24bpp Bitmap for conversion to GBA format in C where you'll find C code which prints out each pixel, and have a look at the wikipedia page about bmp files, because it's very good.

Cross-platform editor control [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I need a cross-platform editor control to use as GUI-part in an in-house tool. The control may be commercial, but with reasonable price.
Required features:
Platforms: Win32, OS X, Linux
UTF-8 support
Fine-grained run-time control to the text style (or at least color)
Nice low-level plain C API without usual horrible bloat
Should not prevent me to have these features (even if I'll have to implement them myself):
Undo / Redo
Copy / Paste
Context menu, depending on click position in text
Toolbar, depending on cursor position in text
Sidebar panel, depending on cursor position in text
Actually above requires not simple control, but whole cross-platform GUI library.
Discarded options:
Scintilla and descendants
FLTK
Fox-toolkit
gtksourceview
Update:
Note: I've slipped in some half-written discard reasoning here, I apologize. Scintilla indeed does work on OS X. However, if I get it correctly, Scintilla's API is in C++.
Use-case:
My use-case is to write custom "semi-rigid" logic editor, where user is free to copy-paste around, add comments where he wishes, even type in text directly if he wish. But text structure is a rigid natural language representation of logic tree (somewhat AST-like in nature). I plan to write something intellisense-like (or code-template-like) to be used as the main authoring tool (instead of typing logic by hand).
BTW, storage format would not be plain text, but instead internal representation of mentioned logic tree (with comments and whitespaces etc. metainfo).
So, I have all necessary information to render text in needed colors by myself. I do not need any external lexers etc.
As John wrote, Scintilla is known to run on OS X.
Now, it is not a rich text component, if that's what you are looking for. It is a source code editor: you can't apply arbitrary colors to arbitrary segments of text, it uses a lexer to style the content.
You didn't tell us what is your use case.
[EDIT] Thanks for adding the use case.
Disclaimer 1: I don't try to "sell" Scintilla, I just try to provide you information about a component I know well, hoping that helps you... :-D
Note that the Related Sites page lists a number of alternative Editing Components which can be interesting (or not, lot of them are for Win32 only).
Disclaimer 2: I have no experience of using Scintilla outside of the Win32 platform.
But looking at the source tree, I see a scintilla/macosx folder. Among other things, it has a SciTest sub-folder with a main.cpp file. Despite its extension, it strongly looks like pure C for me. So it can be an example of how to use Scintilla in C.
Note that by design, Scintilla API is very limited: it was initially made to be used as most traditional Win32 components, by sending messages to it. The Scintilla Documentation page only lists these messages and their parameters. The main.cpp example creates the window with the component in MacOS X style and sends commands with lines like scintilla->WndProc(SCI_STYLESETFORE, 0, 0x808080);
I won't claim it does everything you need, or even that it works flawlessly on MacOS X, you have to experiment (or ask the author of the adaptation) to be sure.
Also Scintilla won't provide a toolbar nor a sidebar panel (this belongs more to the application itself). But I think it can provide enough notifications to help you keeping these side components on context.
You will need also to write a specific lexer (C++ here) for your syntax. It isn't hard if you look how works other lexers. Perhaps you will find one for a language close enough to be used as a starting point.
Perhaps of interest too is a feature to set some portions of document as read-only, although I believe this haven't been thoroughly tested.
HTH.
Scintilla and descendants (no OS X)
But, scintilla does work on OS X.
You could try GTK+ with GtkTextView, or Qt's QTextEdit.
FLTK's TextEditor widget is all you need. It is simple, straightforward, and easy to use, has utf8 and you can easily have text-styles. With just few lines you can have an editor. Check the /test/editor.cxx example. It works perfectly on OSX as well. Furthermore, all you need is explained here: http://www.fltk.org/doc-1.1/editor.html .
Well,
you might be able to use tk -- the text widget is supposedly good and flexible -- have a looksie at the tcl/tk wiki.
Or you could go for some embedded/game toolkit (like Agar) -- but there a text widget with editing capabilities would be more cumbersome, I imagine.
But saying you want to do a cross-platform C GUI and then writing off GTK seems like a whole lot of wasted time and effort, to me. You'll probably end up switching languages or using GTK.

Resources