I basically want to get the outline for a character. I was wondering how I could do this without drawing to the DC. Could I do something like this: (Psudocodeishly)
BeginPath()
TextOut("H")
EndPath()
GetPath()
Will something like this work for GetPath? Will it return the glyph outline that I can then draw?
Otherwise, how else could I do this (without freetype)
Thanks
If you want to get a glyph outline, why not just use GetGlyphOutline? There's the theoretical limitation that this is limited to TrueType fonts, but given the percentage of other fonts typically used on Windows, that's rarely a concern...
Edit: Yes, if you want to avoid using GetGlyphOutline, using a path instead will work (though only with TrueType fonts, not bitmapped fonts). The sample code included with the documentation for CDC::BeginPath shows how to do exactly what you seem to be after (though I'd strongly recommend using std::vector instead of new[] and delete[] as it does). One minor detail: that sample includes an implementation of PolyDraw. You'd only need (or want) this if you need to support ancient 16-bit versions of Windows -- all NT-based versions of Windows include it.
Related
My requirement is to display string of any language on the screen.
Currently we are using opengl to display English characters.
Same APIs are not working for other languages. Instead of characters, boxes are displayed on screen.
Can someone help in understanding opengl and find appropriate APIs to display charterers of any language?
Currently we are using opengl to display English characters.
No, you're not using OpenGL. How do I know this? Because OpenGL does not do text rendering. All it does it points, lines and triangles.
What you're using is some library that knows how to draw characters with points, lines and triangles and then uses OpenGL to get that job done. And the particular library you're using apparently doesn't know, how to deal with characters outside of the ASCII character set.
Of course it's not just that what matters. Encoding matters as well. The most recent versions of C++ support Unicode in program sources (so that you can write unicode in string literals), but that does not automatically give you unicode support in your program – it's just the compiler who knows how to deal with it, but that knowledge does not automatically transpire into the compiled program.
So far there is only one operating system in which Unicode support is so deeply ingrained that no extra work is required; in fact a particular way of encoding Unicode was invented for it, but unfortunately this is one of the most niche OS projects there is around: Plan9
Apart from Unicode, there are also many other character encoding schemes, all incompatible with each other, each for a particular kind of writing. Which means, that it's also impossible to mix characters from different writing systems in texts encoding with such localized characters sets. Hence a universal encoding scheme was invented.
You're most likely on Windows, Linux, BSD, Solaris or MacOS X. And in all of them making non-ASCII-characters work means extra work for you, the programmer. MacOS X is probably the one OS with the least barrier of entry.
So here are the questions you have to answer for yourself:
what character encoding used (hopefully Unicode)?
does the text renderer library used support code points in that encoding?
does the text renderer library come with a layout engine (the thing that positions characters) or does this have to be supplied extra?
Among the existing text renderers that can draw to OpenGL, currently Freetype-GL is the most capable; it has support for Unicode
https://github.com/rougier/freetype-gl
Title says pretty much everything. Once upon a time when I was under 13, my older bro did in BorlandPascal a thing which amazed me. He defined kind of table [8][8] with values of 1 and 0, meaning respectively foreground and background. Having several of such tables he could somehow redefine default ASCII characters to look like in these tables. I have no idea how it was done, but it worked.
My question is: can I do similar thing in ncurses, and if I can then how to do it?
The short answer is no. What ncurses does is generating ANSI escape codes which are interpreted by the terminal. There are no codes for altering the font. (Althou there have been extensions propesed no commonly used terminal supports them, neither does ncurses.) And there is no generic way of communicating with the terminal through some kind of side channel for changing the font. But there might ways in some specific situations.
If you have direct access to a Linux console for example you could could do all sorts of things, much like in Borland Pascal. But it will likely be more messy and less impressive.
As the selected answer explains, this is not possible for NCurses to render custom glyphs. ncurses only manipulates the terminal screen state via escape codes (Clearing and rewriting lines to achieve interactivity).
However it should be noted that's very possible to use custom glyphs in the terminal via custom fonts.
This is what Powerline does (a popular terminal UI status line for vim, tmux and friends): https://github.com/powerline/fonts
By patching the fonts, you can inject your glyphs into the existing font being used by the terminal, which then you can access and render via ncurses as any other character.
Of course this is not ideal solution, but with some auto patching of the fonts, and careful testing, it makes it possible to build an app that uses custom glyphs—when your really in a pinch for more expressive UI tools than ncurses can offer.
Further reading: https://apw-bash-settings.readthedocs.io/en/latest/fontpatching.html
I want to partition the output screen into two parts (just like frames do it in HTML). So that one part may remain fixed and display some content which is updated based on input received from the other part.
I do not wish to venture into GUI stuff therefore OpenGL, SDL etc are ruled out (I wish to do it in command line mode). I have Borland C++ with graphics.h support, but it is just too old to carry on.
What alternatives do I have at my disposal (If not C++, a solution in C will also be Ok.)
You may want to take a look at curses-like libraries like PDCurses.
Other than that, you may use ANSI terminal escape sequences to control the cursor on a text window, this may be quicker if what you are doing is simple, otherwise use PDCurses and it will handle the escape sequences for you.
Check out Curses / NCurses.
I need to draw some pictures for my LaTeX documents, and I've found that hand-made PostScript seems to be a good fit (I want to do stuff programatically, need math functions, etc.). I've also tried TikZ but that just seemed overcomplicated and hard to use.
However, using plain standard PostScript is a bit painful since there aren't really any standard functions for drawing shapes (e.g. not even rectangles).
Is there any PostScript library that would include functions for common shapes and make life a bit easier? Seems to me this problem should be fairly common.
Or should I skip PostScript and move on to some superior system? Which one?
A few people and many PostScript drivers define their own set of procedures for drawing shapes. A PostScript driver may output the following shortcuts:
/bd{bind def} bind def
/cp{closepath}bd
/gs{gsave}bd
/gr{grestore}bd
/m{moveto}bd
/rm{rmoveto}bd
/l{lineto}bd
/rl(rlineto}bd
/s{stroke}bd
/f{fill}bd
/sf{gs s gr f}bd
/xx{exch}bd
/rect {4 2 roll m 1 index 0 rl 0 xx rl neg 0 rl cp} bd
Then, a rectangle would be drawn like this:
0 0 100 100 rect sf
The cumbersomeness of this does make PostScript particularly hard to deal with. MetaPost may be a better fit if you your drawings are programmatically/mathematically generated. MetaPost generates encapsulated PostScript (which you can include in your LaTeX document) but it is more suitable for drawing images with algebraic definitions.
I like using matplotlib. It can generate both postscript and PDF directly, it's in python, and it can also do pretty sophisticated plots (hence its name). If you want to hack PostScript directly you'll be able to use psticks in LaTeX, but you'll need to run-trip everything through dvi2ps and then ps2pdf to make PDFs. Do you really want PostScript or PDFs? I think that you want PDFs, right?
OK, I've decided that Asymptote is the best thing since sliced bread. Handles drawing both graphs and arbitrary figures really well, and has a vast number of extension modules (including MetaPost compatibility if you care about that). Additionally it typesets text using LaTeX which is just incredibly cool. As an added bonus it even outputs directly to PDF (or EPS).
I still think it's a bit sad there's no good libraries of routines for good ol' PostScript though.
I have used Asymptote (for graphs though) but I found it tiresome to learn yet another custom language. If you're familiar with Python, you can give PyX a try. Its feature set is similar to that of Asymptote. For example, it can also use LaTeX for typesetting text/math.
Another option is Enthought Enable, but that is probably less suited.
I've had good results constructing images directly in postscript. One helpful convention I've found is to treat objects like glyphs in a font. So each object expects the currentpoint to be set at, say, the bottom left corner, and leaves the currentpoint at the bottom right. The you can put them in an array and forall through it: each object leaves the currentpoint ready for the next one.
Generate SVG, then use something like iText and/or Inkscape to programmatically convert to PDF/PS. I built a publishing stack this way and it worked out really nice.
There are lots of postscript libraries
look here
http://www.ericlindsay.com/computer/printing.htm
and here
http://www.tinaja.com/post01.shtml
and here
http://seit.unsw.adfa.edu.au/staff/sites/gfreeman/qs.html
I'm looking for a library to save an array of colour data to a PNG file. (That's all there is to it, right? I know very little about the internals of a PNG.)
This is for use in Nintendo DS development, so something lightweight is preferable. I don't need any other fancy features like rotation, etc.
To encode any kind of PNG file, libpng is the way of the walk.
However, on small devices like the DS you really want to store your image data in the format which the display hardware expects. It is technically possible to get libpng working on the platform, but it will add significant overhead, both in terms of loadtimes and footprint.
Have you looked at libpng? http://www.libpng.org/pub/png/libpng.html
I'm not sure whether the memory footprint will be acceptable, but you should probably be aware that PNG files are a lot more involved than just an array of colors. Performance is likely to be a concern on a DS.
If you go with libpng, you'll also need zlib, and if you're using DevKitPro, you'll probably run into some missing functions (from playing with the code for 5 minutes, it looks like it relies on pow() which doesn't seem to be in libnds.) I have no idea what the official Nintendo SDK offers in the way of a standard library - you might be in better shape if that's what you're using.
I managed to find a library that supports PNG (using libpng) and allows you to just give it raw image data.
It's called LibPicture. It's a bit hefty though: ~1MB.