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.
Related
I've had a good look around and I can't seem to find a good answer for this coding quandary!
I'm laying out pages in an eBook style app for iOS (Swift 3), and I'm trying to pre-calculate how many pages each chapter will need. The two main problems I'm having to tackle are:
The page can be viewed in a two / three column layout
The user can adjust the font size (resulting in more/less pages per chapter)
The tutorials and guides I've reviewed to achieve multi-page columnar layouts seem to require you to actually perform the laying-out of text in the UITextView before you can calculate how much text was used.
My ideal scenario would be a means to say 'I have a font of X size and this CGRect... how much text will fit inside this frame?', but without requiring me to perform the actual rendering of said text into the frame before the calculation is made (as you would using something like UITextView's characterRange(at:...)).
Is there any way to accomplish this? Am I chasing a solution for an unsolvable problem?
Thanks for any assistance that can be offered :o)
I have a Windows Store Application. We are using the Multilingual App Toolkit to translate the resources in our app, including the AppBarButtons.
The trouble comes in that some translations of even simple phrases in some languages are incredibly long. What do we do for these buttons? They are near useless if half of the label is ellipsis-ed away ("My bu...").
I've search through the guidelines for what to do in this case and can't seem to find what they expect of us, or what is the best practice for this situation. Should I extend out the width of the buttons? In some cases I have the space to do this. In others, it will make it a bit cramped or I will have to make the buttons not uniform width, which can look bad. Do I make them word wrap? This still cuts some words mid-way in some languages, and can look pretty bad in my opinion. One way to improve that seems to be to align the buttons Top, but that still doesn't fix the mid-word wrap issue.
Does anyone know what the guidelines are for this? Or have any tips as to best practices?
[I'd like to note that, while a part of this question requests opinions as to best practice, the main question I'd like answered is for a guideline specified by Microsoft, as I haven't been able to find one.]
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.
I've got a latex macro that makes small pictures. In that picture I need to draw area. Borders of that area are quadratic bezier curves and that area is to be filled. I did not know how to do it so currently I'm "filling" the area by drawing a plenty of bezier curves inside it...
This slows down typeseting and when a macro is used multiple times (so tex is drawing really a lot of quadratic bezier curves) it produces following error:
! TeX capacity exceeded, sorry [main memory size=3000000].
How can I prevent this error ? (by freeing memory after macro or such...) Or even better how do I fill the area determined by two quadratic bezier curves?
Code that produces error:
\usepackage{forloop}
\usepackage{picture}
\usepackage{eepic}
...
\linethickness{\lineThickness\unitlength}%
\forloop[\lineThickness]{cy}{\cymin}{\value{cy} < \cymax}{%
\qbezier(\ax, \ay)(\cx, \value{cy})(\bx, \by)%
}%
Here are some example values for variables:
\setlength{\unitlength}{0.01pt}
\lineThickness=20
%cy is just a counter - inital value is not important
\cymin=450 \cymax=900
%from following only the difference between \ax and \bx is important
\ax=0 \ay=0 \bx=550 \by=0
Note: To reproduce the error this code have to execute approximately 150 times (could be more depending on your latex memory settings).
Thanks a lot for any help
I admit I don't know how to manage LaTeX's memory. However, there are better drawing frameworks for LaTeX than the old picture environment, that doesn't seem to support filled bezier paths. Two that comes to mind are the modern-style PGF and Tikz (see also examples) and the more ancient Metapost.
For historical reasons the memory available to TeX lives in a static pool where the size of the allocation is hard coded. You can recompile TeX with this set to a larger size, and some versions allow it to be configured at runtime. This FAQ entry discusses it in a bit more detail.
This page discusses configuring memory in MikTeX. Depending on which distro you're using the details will vary but something similar can be done on most modern TeX distros. Some older ones may require you to modify the source.
It seems to me that my question does not have simple and all solving answer.
Using more advanced picture drawing package as Little Bobby Tables suggested caused latex to be able to draw more pictures with some memory size(+- 2 times more) but when drawing more than that the error still occurs.
Enlarging the memory as ConcernedOfTunbridgeWells suggested and then recompiling is something I wanted to avoid. It has also same problem as Little Bobby's suggestion: you can enlarge it 100 times but when typesetting 100 times longer document it will not be sufficient again.
The solution would be to rewrite latex completely as I find this only one of more problems that makes it insufficient for my purposes or use some better typesetting engine(any ideas ?). As I find this too hard I'll be forced to just enlarge memory.