I am attempting to make a very simple label using Libreoffice Draw v 4.0.2.2. The label has not much more to it than regularly spaced lines of centered text
This image will be printed, and I have a fixed size/ppi requirement to ensure appropriate print quality.
I set the page size to my specs, and layout the text as I desire. The print shop takes several image formats including .tiff and .png. When I export the image, a dialog pops up that asks for the image size/ resolution. The given ppi is very low (~40) and I require a minimum of 180ppi. When I enter this, the image size adjusts itself and results in an image that is far too small.
The only solution that appears to be viable is to explode the page size and the drawing text size so it gets shrunk upon export. This is a very imprecise and illogical feature (bug?) of the program that I really wish is a result of my ignorance.
I found a thread in the mailing list which describes this issue exactly. The only answer that is given is essentially "yes, this is ridiculous and doesn't help anybody".
Can anyone give some advice to this? Or at least shed some light on who might need this "feature"?
There is something off about the Export tool of LibreOffice in general. It has been years since it is broken. Taking a screenshot is an alternative, but obviously you cannot control the resolution.
So, a better work around is exporting to SVG, and then convert the SVG to PNG with Inkscape. Once downloaded, convert the file with the following command:
inkscape -z -e out.png -w 1024 in.svg
If you are in Windows (x64), you will need to indicate the full path:
"C:/Program Files/Inkscape/inkscape.exe" -z -e out.png -w 1024 in.svg
If you install the 32 bit version, this should work:
"C:\Program Files (x86)/Inkscape/inkscape.exe" -z -e out.png -w 1024 in.svg
This can be done from inside Libre Office, there is no need to use any external tool. The Export dialog is very confusing, yes; you have to realize that both size and resolution can be set independently.
Select File -> Export -> choose the desired format. The export dialog should appear.
TAKE NOTE of Width and Height. Set the desired resolution; notice how Width and Height change (?). Don't worry, restore Width and Height to your saved values. And that's it. You get a high resolution image with the desired size and DPI.
Libre Draw (the one I'm using anyway) is a vector drawing app - have you asked the print shop if they can use vector formats like eps, pdf? Most should be able to in my experience. Then resolution becomes irrelevant.
-Terry
Related
We have many square EPS images, which we would like to export via script to PNG at very specific formats/sizes, namely
8192x8192, greyscale, no alpha, no anti-aliasing
2048x2048,greyscale, no alpha, anti-aliased.
We have had no luck scripting the "professional" tools Photoshop or Illustrator to do this (although we can do so through the UI, their weak scripting support does not give control over alpha or precise image export size, so we either always get alpha in the large images, or we sometimes get slightly inaccurate image sizes which breaks subsequent algorithms.)
Our first attempt at doing the high resolution version of this was:
gs -sDEVICE=pnggray -o cover.png -dDEVICEWIDTHPOINTS=8192 -dDEVICEHEIGHTPOINTS=8192 -dGraphicsAlphaBits=1 -dPDFFitPage=true cover.eps
However, this does not seem to resize the image to fill the box as expected.
Is there a way, given a square EPS, to get Ghostscript to do what we want?
Your problem with EPS files is that they do not request a media size. That's because EPS files are intended to be included in other PostScript programs, so they need to be resized by the application generating the PostScript.
To that end, EPS files include comments (which are ignored by PostScript interpreters) which define the BoundingBox of the EPS. An application which places EPS can quickly scan the EPS to find this information, then it sets the CTM appropriately in the final PostScript program it is creating and inserts the content of the EPS.
The FitPage switch in Ghostscript relies on having a known media size (and you should set -dFIXEDMEDIA when using this) and a requested media size, figuring out what scale factor to apply to the request in order to make it fit the actual size, and setting up the CTM to apply that scaling.
If you don't ever get a media size request (which you won't with an EPS) then no scaling will take place.
Now Ghostscript does have a different switch, EPSCrop which picks up the comments from the EPS and uses that to set the media size (Ghostscript has mechanisms to permit processing of comments for this reason, amongst others). You could implement a similar mechanism to pick up the BoundingBox comments, and scale the EPS so that it fits a desired target media size.
I could probably knock something up, but I'd have to mess around creating an example file to work from.....
Do not accidentally specify PDFFitPage in the command line above. Specify EPSFitPage when dealing with EPS files. PDFFitPage will silently do nothing.
Am trying to extract data from reciepts and bills using Tessaract , am using tesseract 3.02 version .
am using only english data , Still the output accuracy is about 60%.
Is there any trained data available which i just replace in tessdata folder
This is the image nicky provided as a "typical example file":
Looking at it I'd clearly say: "Forget it, nicky! You cannot train Tesseract to recognize 100% of text from this type of image!"
However, you could train yourself to make better photos with your iPhone 3GS (that's the device which was used for the example pictures) from such type of receipts. Here are a few tips:
Don't use a dark background. Use white instead.
Don't let the receipt paper crumble. Straighten it out.
Don't place the receipt loosely on an uneven underground. Fix it to a flat surface:
Either place it on a white sheet of paper and put a glas platen over it.
Or use some glue and glue it flat on a white sheet of paper without any bend-up edges or corners.
Don't use a low resolution like just 640x480 pixels (as the example picture has). Use a higher one, such as 1280x960 pixels instead.
Don't use standard exposure. Set the camera to use extremely high contrast. You want the letters to be black and the white background to be really white (you don't need the grays in the picture...)
Try to make it so that any character of a 10-12 pt font uses about 24-30 pixels in height (that is, make the image to be about 300 dpi for 100% zoom).
That said, something like the following ImageMagick command will probably increase Tesseract's recognition rate by some degree:
convert \
http://i.stack.imgur.com/q3Ad4.jpg \
-colorspace gray \
-rotate 90 \
-crop 260x540+110+75 +repage \
-scale 166% \
-normalize \
-colors 32 \
out1.png
It produces the following output:
You could even add something like -threshold 30% as the last commandline option to above command to get this:
(You should play a bit with some variations to the 30% value to tweak the result... I don't have the time for this.)
Taking accurate info from a receipt is not impossible with tesseract. You will need to add image filters and some other tools such as OpenCV, NumPy ImageMagick alongside Tesseract. There was a presentation at PyCon 2013 by Franck Chastagnol where he describes how his company did it.
Here is the link:
http://pyvideo.org/video/1702/building-an-image-processing-pipeline-with-python
You can get a much cleaner post-processed image before using Tesseract to OCR the text. Try using the Background Surface Thresholding (BST) technique rather than other simple thresholding methods. You can find a white paper on the subject here.
There is an implementation of BST for OpenCV that works pretty well https://stackoverflow.com/a/22127181/3475075
i needed exactly the same thing and i tried some image optimisations to improve the output
you can find my experiment with tessaract here
https://github.com/aryansbtloe/ExperimentWithTesseract
I want to save a MATLAB figure as PDF, with quality 300 DPI, and centered.
So far I managed to save it, but the image appears cropped. I changed the page type to A3 and kind of solves the problem, but I am looking for something more elegant. I am doing it from the GUI, but maybe from the command line is easier in MATLAB.
Is there any package or script that makes this (fundamental task for publications and papers) a bit easier?
Try using the following command:
print -painters -dpdf -r300 test.pdf
You will, of course, already have to have a file named test.pdf in the current directory.
Some notes on the -commands as well.
-painters: this specifies the use of the painters alogrithm for the exporting.
-dpdf: specifies a vector image, specially a pdf in this case. This is through Ghostscript.
-r300: specifies a 300 dpi resolution. -r400 would be 400 dpi and so on.
On an off note. I tend to just save the figure as a high DPI tiff image and import that tiff into another program where I actually assemble my figure(s) for the paper. I tend to lean towards CorelDraw personally.
I would recommend to check the exportfig package
exportfig(gcf, path_to_file, 'format','pdf','Resolution', 300 )
also, you can check fig package, which is nice to call before the exportfig:
figure
plot(x,y)
fig
exportfig(gcf, path_to_file, 'format','pdf','Resolution', 300 )
I am about the create a bunch of SVG graphics with (probabably) a perl script. These SVG graphics will contain text blocks. Since I want to "connect" such text blocks (of varying widths) with lines I'd like to know what width a text will be so that I can draw the connecting lines' length accordingly.
I have seen in SVG get text element width that it could be possible with java script. But that's probably not what I am after since I don't intend to host the SVG in a browser.
So, I thought that maybe there's a way to find out the desired width at the script's runtime. If someone can point me to a solution (also outside the realm of perl but on windows), I'd be very gratefu.
I did that exactly that about a year ago using PDF::API2 and advancewidth function: https://metacpan.org/module/PDF::API2::Content#width-txt-advancewidth-string-text_state-
Note that you need to correlate DPI of PDF and SVG: they may be different (I actually did that just dividing values by 1.25, you can be better).
PDF::API2 gives you very accurate values that works for Inkscape (in my case) well.
I have a bunch of diagrams created using a Java diagramming tool that I wrote - they are mostly black and white diagrams, with the blocks in aqua, and occasional other colours. They are currently being saved as JPG files, and I want to insert them into a book that I am preparing for Print On Demand.
The book is an OpenOffice ODT file, which will later be converted to a PDF.
Currently I use JPG files, but the print facility they use requires 300 DPI, so I modified my diagramming tool to set the xDensity and yDensity to 300, and resUnits to 1, using getAsTree(), and then expand the diagram by a factor of 3 (300/96). IMO the result looks pretty good!
Unfortunately, someone on another forum pointed out that line diagrams are "fuzzed" on JPG files, so suggested that I change over to PNG, or possibly BMP files, both of which ODT files allow to be inserted.
My problem is that BMPs don't seem to have a DPI, and PNGMetadata doesn't seem to support getAsTree(). Can someone point me in the right direction? Thanks.
I don't understand the getAsTree() part, but answering the question that appears in the title, setting dpi for PNG files, you could use the imagemagick convert tool:
convert -density 300 -units pixelsperinch infile.jpg outfile.png
PNG, BMP and dozens of other image formats don't compress your diagrams - compression is probably what your commentor was getting at. JPEGs are great for photos but suck at diagrams.
You might want to look into SVG and other vector formats. Or if your environment allows, exporting 0% compression JPEGs and converting them into another format for lossless reproduction at 300DPI.
Hope that helps!
I decided not to try to do this programmatically. Instead I create the original diagram in PNG, then convert to 300 DPI using Irfanview. Irfanview's batch capability lets me convert to 300 DPI, scale up to compensate, and set to grey scale, all in one operation - and on multiple files at a time. This seems to be the best solution - but thanks to everyone anyway!