I'm not familiar with CorelDraw, but in Adobe Creative Suite, there are tools to adjust the spacing between lines so you can set consecutive lines as close as you want within the same text box.

It's true that points and picas are artifacts of extinct technology, like furlongs and fortnights. And it's counterintuitive that the 36-point sizes of different faces have widely different cap heights and x-heights. But once you get the hang of it, you can easily tweak the size of a font to the desired cap height or x-height. I usually do it visually rather than with the ruler, or set guides to check alignment.

Like the QWERTY keyboard, the point system survives mainly because that's what the majority of users are familiar with. Anyone attempting to get users to switch to a new system would have to overcome a huge amount of inertia.

Here in the US, where we're more afraid of the metric system than we are of psychos with machine guns, the printer's point serves another useful purpose: At 1/72 of an inch (0.35 mm), it's about the smallest increment that can be seen with the naked eye.

Letters don't fit in straightjackets - what can you do?

[1/72 is] about the smallest increment that can be seen with the naked eye.

Shirly you can't be serious.

hhp

Are there standard ways of dealing with these issues?

Yes: they are called Patience and Discipline. Study them well, Grasshopper…

Are there any units of measurement that are not meaningless (in the way you are defining it)? Feet for example seems quite silly since we all have different sized feet. Meters is even less tied to a perceivable phenomenon. And throw in variations of pixel size on screens and you have no practical way of specifying size even if you had meaningful units.

> How (other than trial and error) am I to select proper "point" size
> in order to get the characters to be a certain height and/or width?

Trial and error is part of the design process. You set type, judge how it looks, and make adjustments until its right.

But if you need a line of type to be an exact width, just make the text box that width (or draw a line or a box onscreen that is that width) and then adjust the type size until it matches that width. No need for a ruler; every drawing program will display the width of objects.

If you want type to be an exact height — for example if you need your caps to be exactly 1" tall for some reason — you can use a similar method of matching the height to a line or box of that height, or you can draw guidelines that are that far apart.

Tip: With many applications you can adjust type size up or down quickly with your arrow keys. Just select the type and then press the arrow. Can be very handy when trying to match a width. See your application's instructions for details.

Quit dumping on the dumpling, his question is entirely legitimate given what he wants to be able to do, and digital technology should enable what people want to do, not force them to operate by trial and error in an arcane system of type sizing inherited from long-obsolete technologies involving little pieces of metal.

Dumpling, there are a couple of different aspects to the issues you are facing. First, let me explain why point sizing of type is meaningless for your purposes. What is scaled when type is specified by point size is the 'body' of the type, which corresponds to the height of the face of the piece of metal in foundry type. Of course, in digital type, this body is invisible, even to the person setting the type. What you have noted is that the visual size of individual typefaces relative to the body height varies. There are sometimes good technical reasons for this, which is why this somewhat arcane scaling system remains useful. For instance, if a type involves more than one writing system with different use of vertical space, or if it includes some particularly tall characters, it may make sense to 'cast the type small on the body' -- to use the old foundry terminology. Another reason why digital type might be visibly smaller than the nominal type size is inherited scaling, i.e. it was cast small in the original metal versions of the design, and subsequent technologies have inherited this scaling (see, for instance, Monotype Perpetua).

Now, what you need for your purposes is a way to scale type relative to visual features rather than invisible body. And there's no good reason why software shouldn't be able to provide you with this functionality. After all, the information you need is present in the font, either in explicit form (e.g. declared cap height or x-height) or in a manner derivable from character identity and outline. I'm guessing that there is some software out there that provides such an option, but I don't know which. The first thing you should do is dig around in Corel's preferences to see if there is some kind of option to scale type by e.g. cap height.

The linespacing issue you mention is related, but a bit different as it is particular to digital type. Fonts have sets of vertical metrics data that software uses to determine default linespacing when software is not using explicit leading values set by the user. Since these vertical metrics data are font-specific, different types will have different default linespacing at the same nominal size. Again, there are good technical reasons for this. The good news is that almost all software -- even MS Word! -- provides means for the user to specify linespacing as an absolute value (usually in point size) for selected text. So you should be able to easily resolve this aspect of your problem.

> And there's no good reason why software shouldn't
> be able to provide you with this functionality

I think newer versions of InDesign can set a word or phrase to a given width (although I've never used that feature), and perhaps other page layout or drawing programs do too.

But while people commonly need to set a *column* to a certain width, setting a particular word or phrase to an exact height or width — such as "I need this word to be exactly 2.73" wide" — is not something that most people need to do every day, and when needed it can be accomplished fairly easily by making a text box that wide and adjusting point size until the width matches. I'm not sure it's a feature that many users are asking for.

And actually I think the point system, while old, works pretty well once you learn it. Subdividing an inch in 72 tiny increments is useful because the difference between, say, 7' and 8' type is indeed very tiny. And applications have been displaying type size in points for as long as I can remember. I know it can be confusing to newcomers, but what alternatives are there for accurately displaying type size?

Keep in mind that type sizes (be it points or otherwise) are not stating the size of the glyph itself, but rather the glyph's bounding box, so it's never a direct correlation.

In CorelDraw you can set how you specify text size by going to Tools >options (Control-J) >text. In the dialog box you can then set the default units to inches, millimeters, picas, points, ciceros, didots, or Q. I don’t know what Q is but 24 points is but 24 points is 33.867 Q.

Character formatting tools are at Text > Character formatting and Text > Paragraph formatting. Adjustments to leading and paragraph spacing, are measured by percent of character height, points or percent of point size. Adjustments to tracking (character spacing in Corel) and word spacing are by percent.

Actually Q is the system that makes the most sense. It's used in Japan, and the base unit is 1/4 of a millimeter.

As for what can practically be done, it's not actually hopeless - here's an idea: every font should have two additional numbers embedded: the ratio of cap height to EM, and the ratio of x-height to Em; this would allow a quick automatic scaling when the user chooses to set the size based on one of those two measures (which however would need to be supported in the software of course). Alternatively, good layout software could actually have the ability to automatically figure out what those numbers are by looking at the font, more than 99% of the time.

hhp

If there is only one line of text, then leading is a meaningless concept.

I have done some shopping online for rubber stamps, specifically date stamps. Character size is expressed in the same units of measure you use for tasks unrelated to typography.

I have designed calendars. I have posted one of them on the "Typography / composition" board, under the title "Page-per-week calendar design".
* For the month numbers at the top of the page, as well as the week numbers at the bottom of the page, I wanted the characters to be of such a size as to just barely fit within certain margins. Only by trial and error could I do this.
* At least in the cells for Monday through Friday, I wanted the date numerals to be centered vertically. Again, trial and error.
* I wanted the numerals at the bottom to be a certain exact distance from the edge of the page. Same deal.

The way I see it is, anything that isn't ink should not be included in the measurement.

@dumpling, but then what would you measure? Which character would you use? Which accent marks?

I know it can be confusing to newcomers, but what alternatives are there for accurately displaying type size?

What's wrong with millimeters, or tenths of millimeters?
Even we Americans divide our inch into thousandths for precise work.

And actually I think the point system, while old, works pretty well once you learn it. Subdividing an inch in 72 tiny increments is useful because the difference between, say, 7' and 8' type is indeed very tiny. And applications have been displaying type size in points for as long as I can remember. I know it can be confusing to newcomers, but what alternatives are there for accurately displaying type size?

The issue raised by 'Dumpling' is not the unit system or how it relates to other unit systems such as inches, but what it relates to in the typeface, i.e. what is being measured/scaled. The fact that the body (em) that the nominal point size relates to is invisible and has no fixed relationship to any of the visible features of a typeface design means that you can't actually rely on it to specify the size of any visible feature. That makes it non-useful for all sorts of purposes. Further, as as typography becomes more and more internationalised, the limitations of such a system become more and more evident. It is one thing for two Latin types to be slightly different visual size at the same nominal size, but another for e.g. the Latin component of an Arabic font to need to be set at 22pt to be of equivalent size to a typical 12pt Latin font. This messes with user expectations of 'normal text size', not to mention the recurring issue of legal requirements for accessibility specified in point size.

Hrant, the information required to comparatively scale types by cap height or x-height already exists in fonts, so adding explicit information expressed as a ratio seems redundant. Software that would need to be updated to make use of such information could just as easily be updated to use the existing data. But the problem with both approaches is that it is terribly Latin-centric (or Euro-centric if you prefer, since the same concepts apply to Greek, Cyrillic and Armenian, although not always compatibly).

What I have in mind is a more radical but global solution, one that could result in all fonts being relatively scaleable to harmonise optically. This would require two things: a standard reference font in which the relationship of outlines to em height would constitute the value 1 of a Standard Visual Size; and a single new piece of information in fonts that would indicate the designer's proposed scaling of that font relative to the standard reference font, e.g. 0.87, 1.14 etc.. This isn't intended, of course, to replace existing scaling methods, but to enable a new way of visually harmonising types of varying on-the-body size independent of writing system.

Robert, it's actually not trial and error. You just have to measure once, and then scale.

the information required to comparatively scale types by cap height or x-height already exists in fonts

Oh, duh. Reinventing the wheel, sorry.
So yes, software would simply have to provide a way to scale to those values.

What I have in mind is ....

So you're saying have an apparent-size quotient? Although of course there's more to matching up multi-script fonts than that. And who would determine that? Eyes vary.

BTW if memory serves this is actually exactly a problem Jorge de Buen has been working on.

hhp

And who would determine that?

The type designer. The whole point is, as you say, that eyes -- and preferences -- vary, so there is never going to be a single, optimal solution. What I am suggesting is a means of establishing a base reference to overcome the most obvious problems of the current system; I fully expect that typographers would want to refine the results according to their own eyes and tastes, but the point is that they already have plenty of means by which to do that. What is lacking is a means to automate harmonious visual scaling according to the Pretty Darn Good criterion. I think the best way to do that is to put it in the hands of the same people on whom we rely to make all sorts of other judicial decisions about aspects of how fonts work: the type designers. What they need, though, is a standard reference against which to make those judicial decisions.

Why does software have me select font size in "points"?

How (other than trial and error) am I to select proper "point" size in order to get the characters to be a certain height and/or width? Seriously.

As noted, you're really asking two separate questions here. The point size doesn't directly correlate to the visible size of the characters. What it measures is the height of the em-square, the (imaginary) type body. Whether you measured it in points, millimetres or pixels, you would have the same problem (viz requiring trial and error).

The great strength of measuring by point size (or em height) is that it doesn't change when the typeface does. This is useful when you may potentially be combining different fonts within a single line at a fixed point size. If you measure line height by a calculation based on the font glyphs themselves, things may not line up properly. Whereas with a em-based line height, any number of 12-point fonts on a single line of type should all occupy the same vertical space.

The actual units are points because, I suppose, that's what people are used to. Since both screen and printer resolutions are normally measured in dots per inch, it's actually a more straightforward conversion than many other units would provide.

On-screen, for instance: At 72dpi 1 point == 1 pixel. At 96dpi, 1 point == 1.33333 pixels. Et cetera.

In CorelDraw, can you measure in"pixels"? If so, at what zoom size is one pixel equal to one pixel? ("At 100%" is not a good answer, unless CorelDraw takes your screen resolution in account. And if it does, then it's still not an absolute measurement because your 100-pixel tall text would be larger or smaller than my 100-pixel tall text. Including the pixel in a list of "real world measurement units" is not simply an error, it's stupid. (And Thank You Adobe for doing so!)

The actual units are points because, I suppose, that's what people are used to.

Unless those people are not used to real world typography. It's no more "weird" than a map that displays distances between cities in kilometers, rather then in inches or millimeters. It's the "natural" way to express text size because it has been like that for several centuries.
In InDesign you can enter font height in millimeters as well (and even in centimeters or in inches), but the system converts them to "points" on entry.

But ... as several others point out above, there is no such thing as "the" font height. That is a notion that's usually even more bewildering for amateurs than the concept of "points".

Mostly, people are more concerned about how many lines fill the inch, rather than how big the letters are, which is why you can't select x-height or cap height from the size menu. It's an interesting feature to add, and presumably today's font formats do make the needed information available.

@ Hrant

[1/72 is] about the smallest increment that can be seen with the naked eye.
Shirly you can't be serious.

I am serious. The printer's point in very precise without being needlessly precise. And don't call me Shirley.

So, let's see if I got this right: Font size, as expressed in points, is strictly a measure of how far down the page your cursor goes when you hit the return key. It has nothing to do with the size of the characters on the page, or indeed anything about the characters themselves, nor how they interact within a single line; all it is is seventy-two times the number of inches the cursor goes down the page when you press return. What this has to do with the font itself is beyond me.

who said Corel measures in pixels, Theunis ?

The fastest sure way in Corel or Illustrator to get type to be exactly the visible cap height you want is to set guidelines to the height you want and then manually fit your text to then. Take a note of the nominal height to set any subsequent text to that height. Or, convert the text to curves (outlines) and adjust the size.

The unit of measurement you choose makes no difference. It's just different numbers for the same thing.

See this? This is what I made, and I would love to automate creation of these using software called FPDF. And the font-sizing system I am forced to work with has all the splendid logic of women's clothing sizes.

@dumpling:
Font size, as expressed in points, is strictly a measure of how far down the page your cursor goes when you hit the return key.

Yes!

What this has to do with the font itself is beyond me.

Well, it describes how tall each of the little pieces of lead-antimony alloy in the font are (or how long, since they're all 0.918" tall)... oh, wait, you're talking about those newfangled TrueType fonts!

It does really seem like design software ought to let you specify font sizes by cap height or lowercase height or whatever. The necessary data is already in the fonts, even the old PostScript Type 1 variety. It's just software running on computers, after all.

Font size, as expressed in points, is strictly a measure of how far down the page your cursor goes when you hit the return key.

No. The distance that your cursor moves down the page when you hit return will only be equivalent to font size expressed in points if the text is 'set solid', i.e. if there is no additional interline distance. Otherwise, the cursor will either move the point size plus some explicit leading value, if that is the typesetting method being used (default in e.g. InDesign), or will move a distance equivalent to the sum of vertical metrics in the font OS/2 table (Windows) or hhea (Mac) table (default in e.g. WordPad), or will move some multiple of the sum of those vertical metrics (default in MS Word).

Let me try to explain point sizing for vector form digital types as succinctly as possible:

The vector outlines defining the shapes of letters, numbers, punctuation etc. in a font are plotted on a unit grid. The fineness of this grid is defined in terms of 'units per em', in which an 'em' is a square that, when scaled, will be equivalent to the nominal point size of text. The em height is directly analogous to what was known as the body height in metal type. So, for example, the vector outlines of a letter might be plotted on a grid of 2048 units per em (pretty common for TrueType fonts). When you are setting text, it is this em that is scaled to the nominal point size. Think of it this way: the em grid is like a canvas on which the letter is painted, and when you scale the text what you are scaling is the canvas, not the letter directly.

.

The printer's point in very precise without being needlessly precise.

I'm sorry I misunderstood you, Victoria. I guess you're simply saying that it's a good scale. I can dig that, but would ask: how often do people end up specifying fractional points? Because picky typographers will often specify something like 10.5 point. And when they don't specify fractional points, how often is that an unfortunate result of a "whatever, dude"?

For example if 1/2 point sizes are commonly specified (I mean by designers who think readers are affected by the difference) but anything finer isn't, then I would say the scale should be twice as fine.

And one thing's for sure, the point must be a pain in metric-system-using countries, which is most of them.

hhp

[diagram deleted]
Since I apparently screwed up the diagram I've deleted it. Maybe someone can post a better one.

Except that's not as correct as the descriptions above.

Yeah James, that thing is highly misleading in at least two ways, sorry.

hhp

Good point, Mark.

**

Why points? It’s all about integers:

Picas and points are nicely scaled to typographical distances — which is the point made earlier about kilometers or miles being the right scale for considering geographical distance.

Picas: if you have to make a table 4½″ wide with 6 columns of varying width? That’s 26 picas, which is an easy number to solve this problem.

Points: if you have to decide between different sizes of type for a particular job, choosing between 8 pt and 9 pt is more manageable than comparing cap heights in inches or millimetres.

Hrant: And one thing's for sure, the point must be a pain in metric-system-using countries, which is most of them.

Indeed.

Pancho Gálvez, in his nice book Educación tipográfica, suggests, IIRC, that one could turn to points/picas for all the measurements on the page. To me that would be impossible.

Just before the worldwide onslaught of DTP software from US companies made it irrelevant, there had been in Europe a proposition of an adjusted Didot point measuring 0.375 mm (instead of the traditional 0.3759), which would make 8 pt = 3 mm, fitting metric pages more easily. I have a nice Faber-Castell typometer using that revised Didot point, and when I used to do this sort of work more often I would reset QuarkXPress's Didot point to this value.

In any case, regarding the thread's subject, we're still talking about the box, not what's inside it. As to this, it's a bit more complex than the original question implies. Even if you mean a plain UC, there may be issues such as hanging J's, Q's tails, etc. And, to be fussy, what about the overshoots.

Points are not meaningless if they are used within one type family, outside those parameters they can often become a stumbling block.

In your example, it is true that a measurement system that reflects those of the rest of the grid might be more useful. However, setting a calendar brings a series of problems that you do not frequently face in other jobs.

For improvements, I would consider kerning and indents and baseline shifts on your dashes.

Tim

@dumpling

Really? All this fuss because you can’t create calendar pages as easily as you would like?

As you may have discerned from the discussion above, there are very good reasons why things are done the way they are done, and not the way you would like to see them done to suit your particular needs…

Rodolfo! Nice to see you back.

Nick, come on. When you're designing display matter and you want the caps (or less often the lc x-height) to be a certain size it takes some extra work that should be unnecessary (considering the data is there in the font). Also, if you want a block of text to harmonize with the rest of a metric-system layout, the point is non-ideal; just like serious fields like science don't use the Imperial System any more, we should switch too (to Q).

hhp

@John Hudson:
No. The distance that your cursor moves down the page when you hit return will only be equivalent to font size expressed in points if the text is 'set solid', i.e. if there is no additional interline distance.

This is true, but it is also somewhat irrelevant, since his statement was simply a complaint that point size has no fixed ratio to x-height or cap height and so on.

Also, there is another exception, at least in some word processors. Sometimes, two fonts will have different baselines, and mixing them on the same line at the same point size will result in the line taking up additional space corresponding to the difference in baselines.

The unit of measurement you choose makes no [material] difference. It's just different numbers for the same thing.

I like to measure with barley corns whenever the opportunity arises.

But the physical page (the thing the stuff ends up on, so has to work with) will be either inch-based or meter-based, so...

hhp

So, I can deal with decimals.

Or rather, my computer can.

:o)

My point in saying that the kind of unit used is irrelevant is that I understand the original question to be about how to determine the dimensions of the visible portion of type and the space above and below.

Ultimately, as designers, why care? If it looks right to your eye, then it is right. We ain't tool and die makers when we make calendars. None of this matters until you have to replicate a layout or build something with real materials, in which case all the data you need is already there. You can round your dimensions off to fit an existing standard or you if feel that that makes life easier, or you can live with something cumbersome like 19.976 barley corns, because you don't need to remember it. (Or even know it.) Your computer does that for you.

While it is possible to obtain that data from the font itself this is already done to a certain extent. llustrator and CorelDraw both recognize the base line.

I design signs for a living and am, always having to set sigle lines of type to specific cap heights and place them in precise locations on sign faces - using the methods described above. When spec'ing for sign shops and design consultants, I'll define the cap height and, if I am concerned they might have limited skills in the field, I provide the size in points that will produce the size of text I want. I.e, to get a cap-height of 25mm, and in brackets, I specify 106 points* (for ClearviewADA).

* 0.149 points, or 0.053 mm or 0.0021 inches too large, which is an acceptable magin or error

It goes like this:

I'm trying to automate the process of generating the calendars. The key word here is "automate".

My goal (it remains to be seen if I will reach it) is to set up an online service to generate just this sort of calendar on the fly. I intend to use software called FPDF for this. (Maybe this is the wrong software. I don't know. But I'm not going to spend hundreds of $$ for something that will turn out unusable anyway.)

Now. I'm in America. We do not use A4 paper here. I originally designed my calendars for A4 paper, and I found out the hard way that nobody around here has it. Another thing I found out is that dealing with available paper margins is a pain, and a rather expensive pain if you go to get your calendars printed and get them all off-center because you went closer to the margin than their machines are set up to support.

So. I am planning on setting up a service where the user specifies what paper size she has available, and how close to the edge of the page it will print. I will probably have a test page or two so she can see how her printer deals with margins. She will of course also specify what time period she wants the calendar for, which (if any) region's holidays she wants on it, etc. Maybe there will be an option for her to choose the typeface. (I like DIN, but maybe she doesn't. Any ideas, folks?*) And as the calendar will be generated without human eyes to look it over, I need a way to get character size and position from point size and position.

* I cannot use typefaces with weird licensing requirements. I don't want the user of my site to have to specify how many copies of the calendar will be printed, whether their use is commercial or non-commercial, etc. (What if the calendars are being used by a business for the business's internal use? Is that commercial or non-commercial?) I'm not a lawyer and I can't afford a lawyer. So I must use fonts without strings attached.
In an ideal world (ideal for me, at least), the typeface designer would be paid a fair, flat fee for their labor, and then the typeface would be released into the public domain. But this is not an ideal world.

Why not just offer a selection of several fonts, and then predetermine (by manual testing) what size works best with each of those fonts?

In an ideal world (ideal for me, at least), the typeface designer would be paid a fair, flat fee for their labor…

Ah-ha, Dumpling is a communist!

@Hrant: …if you want a block of text to harmonize with the rest of a metric-system layout, the point is non-ideal…

I always set the page size units to be in picas, whether metric or imperial.
Then the margins and gutters come out to be manageable integers.

Here is a Letter-size layout I did with horizontal metrics in picas of:
3 + 14 + 1½ + 14 + 1½ + 14 + 3 = 51

A comparable layout for A4, in centimeters would be:
1 + 6 + 0.5 + 6 + 0.5 + 6 + 1 = 21

Not bad, but needs a bit more width in the margins and gutters, I would say.

The body type is 9/12 and the headline 24/30 in points.
That’s 3 mm on 4 mm (2 on 4 if one goes by cap height), and 8 mm on 10 mm.
Not bad, but the difficulty arise for the “next” body sizes.
If I had decided that the leading should be less, it’s easy to take it down a notch (or half) in points—9/11 (or 9/11½)—but that would be 3 on 3.8 (or 3 on 3.9), which makes figuring out vertical metrics of the page more complicated.

Perhaps I am wrong on this; I’d be interested to hear from designers who work in metric how they handle similar layouts—I might even theorize that the units used have some influence on cultural style.

I always define my page layout using pica/point measurements, because I work outwards from the text rather than inward from the page dimension. If the paper size is metric, resulting in fractional points, I absorb these in the inside margin so that my text block and outer margins are integer measurements.

I too find that picas work well for page layout.

Robert, it sounds like -if you want to do this right- you need to write a plug-in for InDesign that accesses a font's metrics information.

In an ideal world (ideal for me, at least), the typeface designer would be paid a fair, flat fee for their labor, and then the typeface would be released into the public domain.

That does happen sometimes (it's happened to me, with Arasan) and it's called commissioning a custom design! But it's not cheap (because it shouldn't be).

I work outwards from the text

When you have freedom of paper size (like I had when I made my letterpress business cards) that's a wonderful thing. But more often the paper size is pre-determined, and you can't just ignore that.

hhp

@russellm:
I like to measure with barley corns whenever the opportunity arises.

Well, as there are two (Selectric Composer or laser printer) picas (and, hence, 24 points) in a barleycorn, that isn't too confusing.

Hrant: But more often the paper size is pre-determined, and you can't just ignore that.

Of course you can't ignore the paper dimensions. But you can start from those dimensions and work inwards, as typified by modernist grid systems, or you can start at the level of letters and words and work outwards. Practically, there's always some back-and-forth, but as first principles they embody different design philosophies. If the first question I am asking is 'What size should the text be in order to be comfortably read in X typeface?', this implies something quite different from first asking 'How should I best subdivide this A4 sheet for the purposes of this document?'. Both are important questions that need to be asked, but the order in which you ask them is also important.

@Robert --
* I cannot use typefaces with weird licensing requirements. I don't want the user of my site to have to specify how many copies of the calendar will be printed, whether their use is commercial or non-commercial, etc.

Such comments tell me there are a lot of things besides the point system you don't understand. Personally I think you are setting yourself up for an expensive FAIL because of all the things you don't know.

Forget lawyers; hire an experienced production artist, even as a consultant -- someone with about five years or more of experience. If nothing else you will learn a lot from them.

Well, I suppose there's always:

As it turns out, I am able to use the baseline as a reference point, which makes things much easier. Now all I have to do it find the conversion factor between points and millimeters. (More trial and error, I guess.)

Here is a little "demo" of what I have so far: http://pdf52.comyr.com/phpstuff/pdftest2.php

I know it is not nearly finished.
* I have hard-coded start and end months as January 2013 and March 2013, respectively. Ultimately, the user will choose the months, as well as many other options.
* If all goes according to plan, the finished calendar pages will have the same sort of information as in the sample page I posted earlier in this thread. (week numbers, sunrise / sunset times, moon phase info, local holidays)

Boy, it is surprisingly simple to come up with something that looks like it rivals a commercial product. Well, not quite. The (lack of) alignment of weekday abbreviations with date numerals is something I need to work on.

I intend to make this available as a free, public service. Any profit will be made by sale of physical, paper calendars, as well as possibly commission fees for custom calendars.

Now all I have to do it find the conversion factor between points and millimeters. (More trial and error, I guess.)

I brought this up before: which part of a simple calculation is trial and error?
1 point = 1/72 inch
1 inch = 25.4 millimeters
So 1 point is ~0.353 millimeters

But, yet again: you still can't predict how large parts of letterforms will end up in the Em square, because there are ballparks, but no benchmarks.

hhp

I believe the expression is "apples and oranges".

I want to know, if I want the characters on the page to be a certain height (think of using a wooden ruler to measure characters on a sheet of paper), then how many points do I tell the computer to use for the em sizeit uses internally to generate the page?

By my zeroth approximation (aka wild-ass guess), you'll need a number that is the app's em divided with the summed fractions of ascender and descender.

Sample for a made-up combo of app and font: 1200/(650+150)

where random_app's em is random_font's em of 1000 + its leading of 200, the tallest ascender is 650 dits above the baseline and the deepest descender reaches 150 dits below it.

Btw, 'dit' is very likely not an accepted technical term.

@dumpling:

Although you've probably been bashed enough by the greedy money-grubbing type designers around here for these comments, as they involve some factual misunderstandings, I feel I need to respond as well, although hopefully in a constructive manner.

I cannot use typefaces with weird licensing requirements. I don't want the user of my site to have to specify how many copies of the calendar will be printed, whether their use is commercial or non-commercial, etc.

Ahem. You won't have to worry about that. One of the first weird requirements of any license agreement with weird requirements is: if you give access to the font to anyone else that gives them the opportunity to lie to you, and hence you let them break the agreement because you've been fooled, it's your fault. Your obligation under the license agreement is to control access to the font so that breaches are impossible.

Also, most licensed fonts are licensed for use on one computer, by whoever is sitting down at it. If somebody else wants to print something with that font, they can buy their own copy.

In an ideal world (ideal for me, at least), the typeface designer would be paid a fair, flat fee for their labor, and then the typeface would be released into the public domain.

What's the obvious problem with this?

Who decides which fonts are worth the expense to have commissioned in this fashion?

The free market has a certain usefulness for which substitutes have not been found.

I want to know, if I want the characters on the page to be a certain height (think of using a wooden ruler to measure characters on a sheet of paper), then how many points do I tell the computer to use for the em sizeit uses internally to generate the page?

Usually, the "point size" for a font to the computer is what it uses on a printed page. It's the size of those letters on the screen that is not controllable, as users can set it to be bigger if they have poor eyesight.

Incidentally, there are 72 points in an inch (in letterpress, a point is slightly smaller, 0.013837 inch), and 2.54 centimeters in an inch, and, of course, 10 millimeters in a centimeter.

So a point is 0.3514598 millimeter or 0.3527778 millimeter.

John, I hope you were kidding in your opening comment. The money grubbers aren't here. And the real money-grubbers aren't even in type.

hhp

BTW, once upon a time, type foundries created special fonts specifically for making calendars, and everything lined up perfectly. Perhaps you should consider doing the same…or commissioning a competent professional to do so…

By the way... you have thought of printing "SydSydSyd" at 100 points and measuring that to get some starting numbers?

@hrant:
John, I hope you were kidding in your opening comment.
Yes, despite the lack of a smiley, which I felt was unnecessary, as I felt I was being obvious.

@ Hrant: I use fractional point sizes all the time, but not because I think readers can see the difference. On the contrary, I often use them precisely because most readers can't see the difference, e.g., in a situation where I've designed a layout to fit a block of text at 12 pt, and some hotshot editor adds another sentence so it doesn't fit anymore. Presto, 11.5-pt type to the rescue.

@dumpling I'm still a bit confused as to your dilema. I think you are struggling with two issues.

1) Converting points to a unit of measurement you'd prefer. Hrant gave you the forumla for that. That's simple math, no big deal.

2) Measuring the height of the printed glyph. This is the part you can't readily do based on the 'type size', since the point size of type refers to the bounding box that all the glyphs have to fit in.

There's no 'fix' for within the font file. This simply because most fonts will have glyphs of wildly varying heights. A simple example being a 'g' vs. 'Q'. But then you also need to account for punctuations, special characters, accent marks, swashes, ligatures, etc.

Programtically, you might be able to fix this by rendering the type and then some how evaluating the generated pixels.

I often use them precisely because most readers can't see the difference

But you made that text block fit for the benefit of the reader, right? Even if we might often be talking about looking, not reading. Note BTW that I said that readers are affected, not that they consciously notice.

hhp

you made that text block fit for the benefit of the reader, right?

Well, sort of right, assuming the reader benefits from my also having room for a headline, a subhead, a couple of images, and maybe a logo and phone number ;-)

I'm a bit puzzled also as to where exactly the problem is. If the idea is writing some PHP to generate calendars, presumably it's not as simple as having the program look at the font's metrics to get the cap height and ascender height relative to baseline and then doing the arithmetic to fit this to the space available. What else needs to be done? Is it the widths that are the problem?

I learned from Eduardo Danilo to start by defining a paragraph font style and then to work a grid from the leading measurement.

By the way... you have thought of printing "SydSydSyd" at 100 points and measuring that to get some starting numbers?

Who's Syd?

No, but I printed "250pt" and "350" in those respective sizes, together with rectangles of known dimensions (10 mm x 50 mm or 10 mm x 100 mm) for comparison. I learned:
* On the printer I used, the rectangles came out a bit too small (about 93 mm for 100 mm). I think it had to do with the page margins I chose and automatic page scaling.
* The vertical measurements were ever so slightly (by a fraction of a percent) inconsistent with the horizontal measurements.
* The overshoots (is an "undershoot" still called an overshoot?) were indeed there. Each over/undershoot is on the order of 1/140 (darn near impossible to measure accurately with the tools at hand) of the total character height.

The thing with overshoots is, once you see them, it's kind of hard not to see them, which defeats their entire purpose. I have seen signs with very large lettering on which the overshoots were laughably obvious. You probably have seen such signs too. Perhaps along with "Bold" and "Italic" options for a font, there should be a "No Overshoots" option!

I have seen signs with very large lettering on which the overshoots were laughably obvious.

That's because a font's overshoot depends on the intended usage size range (or to be picky, the intended subtended angle) and using a font at a size outside that range is, well, blasphemous. :-)

hhp

If overshoots are the problem, then use a “square“ typeface—like this…

http://www.myfonts.com/fonts/nicksfonts/warp-three-nf/

:Þ

Syd = Sunday sans u, n and a. Also the letters I guessed as most likely to give a good measure for caps, descender and ascender.

That would be Hhp. :-)
Actually I'm not kidding - I once saw a presentation by Matthew Carter where he showed that.

hhp