I have a program that prints every client's order, like restaurants tickets, but I made it with times new roman. The result wasn't a quality print. I believe that the font is not the best for this tech and I have to convince my client the owner, cause he loves that font.
Would sans serif or similar be the better choice?
Also, is there a standard procedure for printing direct to those thermal printers and choose the internal fonts, whatever the manufacturer is?
I am using QuickReports to create the printing. The result is king of blur. I will put the pictures to compare as soon as I put my hands on a scanner.
Selecting the optimal print font is both subjective and technical. Not all fonts are suitable to small-dpi mediums; Some fonts use highly variable line width when painting the letters and that will "smudge" easily when used with smudge-prone mediums; I guess the thermal printer fits into both "small dpi" and "easily smudged" areas.
In my opinion the selected font should be, based on priority:
The device fonts: don't print graphics to tiny printers, use the on-board fonts and learn the "escape" language. Results will be outstanding, and there's enough flexibility to also get beautiful results. The only time I had to deal with a thermal printer I used this method and the results really are great. The device allows font scaling, drawing lines, almost everything you'd need. But it is hard work and you'll be outside of the "comfort zone". The printer driver is not helping you at all and you end up writing device-specific routines.
Next option would be BITMAP fonts. That is, don't use True Type Fonts. On today's computers bitmap fonts only serve one purpose: look good at small pixels count. That's perfect for a small-dpi printer.
Invest millions in developing a special purpose font that's easy to read on paper and behaves good printed on whatever device. Or use the font others have spent millions in developing: open your favorite version of Ms Word, type a few words and see what font is used. Right now I get Calibri.
Use a font that doesn't have fancy strokes that need many pixels to paint OR make smudges more obvious. Write something in Times New Roman in very large font. See the fancy lines, the narrow segments, the elegant design? That's not a good choice for a small-dpi, smudge-prone printer. Now do the same for Arial, Verdana, Tahoma.
Let the user choose. This decision is only partly technical, there might be subjective reasons to use one thing or the other.
Related
I've never done OpenGL, but I'm looking for some pointers on this particular question on an AR app I'm practicing with.
I'd like to make an app with a "flat rectangle" along with text written on the surface of the rectangle. Visually, I'm imagining something along the lines of a piece of paper with text written on it. Each time the app starts, the text would be something different (the text is pulled from a plist file).
The user would be able to view the paper from all sides, much as if there was a piece of paper hanging in front of him.
Is this trivial to do in OpenGL? How could I get started?
Sorry for the really open-ended question, but I wanted to get a feel for how this kind of thing is done.
Looking at the OpenGL template source code in the Xcode sample projects, I see that there is a big array of vertices. I presume that to create a "flat" rectangle, I'd essentally just have to remove or make the z-axis zero. And then the dynamic text that will attach to the surface of the flat rectangle...I dont have any idea how to do that......
This question is hard to answer unambiguously. In general, this is trivial, but then again it is not.
Drawing a "flat rectangle with something on it" is a couple of API calls, as simple as it can get. Drawing text in OpenGL in an efficient way, and high quality, and without big preprocessing is an entirely different story.
What I would do is render text using whatever the "normal system-supported" way is under iOS (just like you would draw in any window, I wouldn't know this specific detail), but draw into a bitmap rather than on the screen. This should be supported, pretty much every OS has supported this for at least 10-15 years. Then turn this bitmap into a texture, bind it, and draw your trivial flat quad with OpenGL (set up a vertex buffer with 4 vertices, each vertex a texture coordinate, and draw two triangles - as easy as it gets).
The huge advantage of that is that you get to use the installed system fonts (or any fonts available), you don't need to generate a bitmap font and don't need to think about really ugly things such as hinting and proper spacing, and it's much easier to mix different text styles, etc. OpenGL has built-in support for text too, of course, but it is not terribly efficient or nice either. If the text does not change every millisecond, it's really best to render it using the standard renderer that the operating system provides (yes, that probably won't be hardware accelerated, but so what... since the user must read the text, it likely won't change every millisecond).
Now it gets more complicated if your "piece of paper" should bend and twist too, or do a page peel effect rather than being just a flat rectangle. In that case you need to tesselate it, which can be harder than it sounds, too. Not all tesselations look optimal for all bends/twists, or they do but do not have the optimal (read as minimum) number of vertices.
There is an article on "page peel" and such tesselation in one of the GPU Gems or GPU Pro books, let me search...
There: Andreas Bizzotto: "A Shader-Based eBook Reader - Page peeling effect", GPU Pro2 pp. 278-299
Maybe you can get hold of a copy or are lucky enough to find it on Google Books or something.
Is it possible to generate a specific
set of font from the below given image
?
My idea is to generate a specific font
for the below given image of text ,by
manually selecting portion of the
image and mapping it to a set of
letter's.Generate the font for this
and then use this font to make it
readable for an OCR.Is generation of
font possible using any open-source
implementation ? Also please suggest
any good OCR's.
Abbyy FineReader 10 gets better than expected results but predictably gets confused when the characters touch.
Your problem is that the line spacing is too small. The descenders of each line overlap the character bounding boxes of the characters in the line directly below. This makes character segmentation almost impossible because the characters are touching and overlapping. The number of combinations of overlapping characters is virtually impossible to train for. The 'g' and 'y' characters are the worst offenders.
A double line spaced version of this would probably OCR reasonably well.
A custom solution that segmented and separated the each line along with a good dictionary would definitely improve the results. There would still be some errors to correct manually though. The custom routine would have to deal with the ascenders and descenders and try and segment the image into lines which can then be fed to a decent OCR engine. One way would be to analyse every character blob on the page and allocate it to a line. Leptonica (www.leptonica.com - C Imaging Library) would probably make this job a little easier.
I would not try this without increasing the resolution to 200 or 300 dpi first.
With this custom solution, training a font becomes an option if the OCR engine does a poor job initially.
Abbyy (www.abbyy.com) or Google Tesseract OCR 3.00 would be a good place to start.
No guarantees as to whether all of this will work though. This is quite a difficult page to OCR and you need to work out whether it is better to have it typed up manually overseas. It depends on the number of pages to need to process.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am preparing a presentation in latex using the beamer package. I am wondering what font size "pros" who give a lot of presentations use to make sure people in the back of the room can see. The default font size seems a bit small to me.
With beamer, I always use
\documentclass[14pt]{beamer}
The actual font size is larger than 14pt because of the scaling that beamer uses.
The font should be generously large, so that everyone can see it: for typical talk situations font size is not the main constraint, but amount of information being displayed per size.
The advice I generally heard has been to have very few slides with more than 10 to 12 lines of content on them, including the slides heading. The beamer manual suggests that its default of an 11pt font (onto a quite small page, so this is not as small as it sounds) leads to a maximum of around 20 lines on the page, which seems to be rather too high.
By contrast Powerpoint uses a default font size of 17pt, which gives much better amount of information, but often seems to lead, to my taste, to somewhat bombastic presentations.
The middle of this range, around 14pt, seems a good median.
Some further considerations:
I am not a beamer expert. I usually handwrite my slides!
You can justify using rather bigger fonts, to give a point some punch, and sometimes you have a complex idea that is best presented all at once. Variations in the amount of information of the slide should be accompanied by variations in how you present that slide: this is easy with less information, but the risk with more information is that you don't guide the audience through all of what you are presenting properly.
You generally should read out everything on the slide. If this seems silly for some piece of content, it probably shouldn't be there. Don't be tempted to fit large pieces of code on a slide and expect the audience to just absorb what is there: chop out the bits that matter and explain them properly.
When making a presentation your concern should be the readability of projected text. Terms such as 12pt, 16pt are really for type on paper. When projected your text might be 10cm in x-height on the screen in a large hall. There is no good alternative to rehearsing in the room you will be making the presentation in, and checking the legibility of text from the furthest seats.
There are a lot of factors which make rules about type on paper inadequate for guidance on type on a screen. Some of these are:
the difference between the high resolution of laser printers and the generally lower resolution of projectors;
foreground and background colour combinations which work well on paper may work very poorly on screen, and vice-versa;
even the quality of the projection screen has an impact on the readability of text.
This will vary greatly on your screen resolution and on the size of the projection screen.
Charles and I clearly disagree! I've just beamer a fair few times for talks and just left the default sizings as they were and got good results. I believe Beamer is designed with a similar mindset to LaTeX: it uses defaults that are good enough for the intended use.
In my talks, I use Futura as my main font, which is very readable at large sizes. Relevant bits of my standard preamble follow. (I use xelatex btw, which makes font switching much easier)
\usetheme{Copenhagen}
\usefonttheme[onlymath]{serif}
\usepackage{fontspec}
\defaultfontfeatures{Mapping=tex-text}
\setsansfont[Ligatures={Common}]{Futura}
\setmonofont[Scale=0.8]{Monaco}
You want something "rounder" than you would use for handouts. Also sans-serif. Beyond that it's probably not that big a deal.
I've used Futura and Gill Sans (Keynote's default font) in the past. Calibri (PowerPoint's default in their latest version) is nice. Gotham is a very popular font, too.
I have to extend an OpenGL-Rendering system to support international characters (especially Hebrew, Arabic and cyrillic).
Development platform is Windows(XP|Vista|7), alas using Embercardero Delphi 2010.
I currently use wglOutLineFont(...) to build my font's display list and glCallLists(length(m_Text), UNSIGNED_SHORT, PWchar(m_Text) ) to render my strings.
While this is feasible for Latin-1 Characters, building the full Unicode character set in advance is pretty time-consuming (about 8.5 minutes on my machine), so I am looking for a more efficient solution. I thought about limiting the range from u+0020 - u+077f (Latin, Greek, Cyrillic, Arabic and Hebrew) to include just the glyphs I need, but that would just be a solution for my current needs, and will become insufficient once other encoding is needed.
On the upside, I do not have to worry about left-to right or right-to left direction as our application can handle this already.
I would expect this to be a well-known problem, so I would like to ask if there is any reference material on this on the web, or if you could share some insight on this?
Edit
A clarification: I use a polygonal font representations. Each Font is constructed at unit size (1.0) in advance and scaled appropriately using glScalef(...) before rendering. I did decide against pre-rasterizing since the users might zoom in quite closely (The application is used for CAD), so rastering artifacts would become visible.
Additionally, since a scene seldom exceeds more then a few hundred characters (mainly labels and measurements), the speed gain from pre-rasterization is negligible.
Don't pre-build the display lists :- create an intermediate sprite that builds the lists on demand, and caches them. Trying to pre-compute lists - or pre generate rasterized textures at every font size, font face, and for all characters, is impractical, Especially when you scale to far eastern character sets.
You need to replace the wglOutLineFont.
To do that, generate/render to texture the required glyphs using the wglOutLineFont, and then save the texture into a raster image file. Once application loads, it needs to load the texture image and the glyph texture coordinates (4 coords for each glyph), and to generate the display lists (one list for each glyph, each display list shall draw a single glyph as textured quad).
Each short representing a glyph shall have a corresponding display list (their value much match, and glListBase can aid in this).
I suppose loading a texture is faster than generating font display lists at runtime. Pratically you move offline the glyph raster computation. But the display list generation can be heavy (many glyphs). Indeed you can run in a separated thread the display list generation or generate only the display lists required by your needs.
I've had good luck transliterating this tutorial into C++, though I'm not sure how well it will transfer to Delphi.
I use a non-default Windows colour scheme on most of my machines, and have a laptop with a 124 DPI screen, which Windows is set to.
A lot of programs I tested or even use daily seem to have problems with that, showing for example non-standard sizes of controls, cut-off UI elements, unreadable text and so on. There is the whole range from slightly annoying to (nearly) unusable.
Now I feel that a lot of these issues are unnecessary. A simple test run on a high-resolution screen in a few colour schemes would show them, some of them are even very easy to correct (like always using clWindow, clWindowText and clBtnFace instead of clWhite, clBlack and clSilver). Some of them are harder, like proper control sizing.
So my question is: Do you try to follow the recommendations in the UI guidelines regarding system colours, sizing and spacing of UI elements, and font sizes and faces? Is testing for compliance to them part of your QA process? Do you even try to lay out your forms in dialog units instead of pixels, even though most of the IDEs (Delphi in my case) have pixel-oriented designers?
[EDIT]: On re-reading this after sleeping I notice that this question may look like an invitation for fruitless discussion. It is not meant that way, I'd definitely be interested in tools to help me create applications that conform to the UI interface guidelines, an area where I feel Delphi is letting me down a little. See also my own answer.
I definitely don't. It costs time that I prefer spending on improving the experience of many rather than the few who use non-standard windows settings. A few things I usually do, which should still fix some of these issues:
use clWindows etc. because that's the standard for Delphi controls anyway, so why change it?
place labels above entry fields rather than to the left, which should solve many size problems
make sure the forms resize properly, by setting the anchors
make sure the tab order is correct (which can become a major annoyance if not done)
But I certainly don't take the time to set up test computers with odd resolutions and colors, or even worse, change my development box to use them (which will screw lots of things that again take time to reset properly).
If a paying customer reports problems with non-standard settings, it depends on the customer whether they will be addressed. If he orders 100 licenses, his chances are good. If he uses these settings because he is visually impaired, his chances are good. If he makes it part of the requirement, I will do it, but charge for the additional work.
Today, so much software doesn't work properly at a non-standard DPI that I don't think it's worth trying to fix it. The trouble-shooting FAQs for many applications just instruct users to switch to a normal font size for related problems. Microsoft acknowledged lack of proper DPI support in 3rd-party software and redesigned the display scaling methods in Windows Vista, where all GDI operations are scaled on a low level instead of relying on applications being aware of the DPI setting.
Final answer: it depends on your software's audience. If your software is likely to be used by disabled users, it might be worth the effort.
Apart from using the proper colour constants for standard colours I invest some extra effort for applications that we need to use internally on high DPI screens, or where customers may need this.
I have a unit with helper functions for determining proper sizes and placement margins, which compute these from the default GUI font and the standard values in dialog units as given in the UI guidelines, and with helper functions to compute the maximum width / height of an array of controls, place controls, things like that. For fixed size forms and dialogs I calculate the placement of controls once after translating their text with GNU gettext, for resizable forms I do this in an OnResize handler.
This gives good results, is however time-consuming. I would like to have something like the wxWidgets sizer functionality, which automates resizing once the minimum size of a control is set. I have never seen something similar for Delphi, though.
I occasionally test it myself for large fonts, because my Vista laptop is set to Large Fonts. Colors, not so much, but I rarely specify colors on controls.
However, proper resizing is pretty hard. I usually set Forms scale to false, so as that they won't resize wrong.
There are a few tools for auto-resizing forms. I did look into them, but never got around to testing them properly:
TFormResizer
ElasticForm - ironically (given the component's area) most of the text in this page won't show up in Chrome...
JVAutoFormSize (in JVCL - doesn't seem to be very useful from what I read)