I'd like to display some sheet music in my WPF application which was generated by Lilypond. Lilypond can make postscript and PNG files - I've got the latter working, but I'd much prefer the former so that the music can be resized nicely. Is there a way to do that?
Simplest, but perhaps distasteful to many, would be to shell-out and use an external program render the postscript to png. You'd probably want to display some generic "working, please wait" message, as making an accurate progress-bar would be quite a chore.
Alternately, ghostscript can be used as a library and can read the PS from memory and render to memory, potentially saving some disk-access.
Related
I know few about this and i'm trying to keep building upon it. My goal is to do image stacking with some criteria using C language, as i came upon some cool ideas i think i should be capable of doing with my photos. My C background should be enough to understand what i may need. That being said...
So far i've learned how to read an existing .TIFF file and save it into a char array. The problem is i don't know in which way its data is contained so that i can then be able to analize individual pixels and modify them, or build another .TIFF file from data i previously read.
I've read some things about (a so called) libtiff.h which may be usefull but i can't find where to get it, neither how to install it.
Does anyone know how a .TIFF file data is stored so that i can read it and apply changes to it?
Also,
Does anyone have any experience with handling image files and editing in C? Where did you learn it from?
Do you know of any place i could search for information/tutorials?
Any help will be very usefull,
Thanks in advance.
You can do an enormous amount of very sophisticated processing on TIFFs, or any one of 190+ other formats with ImageMagick without any need to understand TIFF format or write any C. Try searching on Stack Overflow for [imagemagick]
If you want to do processing yourself, consider https://cimg.eu
Another option might be to convert your TIFFs to NetPBM which is much, much simpler to read and write in C. That would be as follows with ImageMagick:
magick INPUT.TIFF -compress none OUTPUT.PPM
I have ahead of me a fairly specific task, and I was hoping someone on this site can give me the benefit of their experience
I have a text file somewhere with some 17000 lines of text. This text will need to be printed very specifically on around 80 double sided pages. These pages will then be cut into several pieces, and bound into small books (hey, it's a hobby!) This means I need to have text placed very specifically on the page. (I am also toying with the idea of having text cut off mid letter in one place and continued elsewhere)
Note that I have done this before, by manually placing text using a word processor. However, the sheer magnitude of this project really requires programming. I have thought about making some PNG files (which is easy enough to do), but I do not know how nicely they will look when printed. I have also briefly looked at some standard document file formats (like doc and pdf) and it looks like it'll take a long time before I can learn these last.
Does anyone happen to have any helpful tips, or at least know the best file format to use for such a project?
Thanks
The best recommendation I'd give is to use C to parse the input and generate a latex document, which is in turn used to generate a pdf for printing. Although it might seem more complicated, latex is much more flexible when it comes to typesetting placing manually the text in a bmp file for example (basically, latex is a language that consist of a set of rules to specify where and how a text should be printed).
Paul92 mentioned LaTex which is one option I'd consider. The learning curve can be quite steep but it will undoubtedly do a nice job with your text if you're willing to fuss with it.
If you're feeling a bit more 'rough and ready' you might consider markdown. It will keep the source text a bit more readable, and there are some reasonable options for getting from markdown to a nice print out.
I want to be able to use OpenGL to create a video output file instead of the usual display on screen output. I am thinking by not using glutPostRedisplay() or (SFML version, which is something like this:) window.Display(), and somehow using glReadPixels() instead.
glReadPixels puts the pixel content into an array in memory (as you might already know) but how can I convert that into a frame, and string several frames together in a video file? And what format would the video file be in, so that I can play it?
I should explain why I want to do this: A lot of physics simulations can take a very long time to calculate enough information to display one frame, so it's better to leave it running overnight and play the video file the next morning. You wouldn't want to keep coming back every 5 minutes to see what had happened.
glutPostRedisplay is part of GLUT and not something specific to OpenGL.
You normally do offscreen rendering using either a PBuffer or using a hidden window and a framebuffer object.
Converting a image into a video can be done in various ways. For example you could utilize FFmpeg using image2pipe as input format and write the raw image data to the ffmpeg process standard input. A much simpler scheme would be to dump each frame into a separate image file. Using libpng is straightforward. You can then merge the individual images into a video.
However when doing physics simulation you should not dump the final rendering into a file. Instead you should store the simulation data for later playback, as you then can adjust rendering parameters without having to re-simulate everything. And you will have to make adjustments to the renderer!
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.
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:-)