Ellipsis and diphthong spacing problem
John Button
with a vengeance now we're setting more language studies academic
texts...
A few characters, particularly the ellipsis and the diphthongs, do not
correctly occupy the correct horizontal space in the text line; they
take up less space than they should, resulting in overlapping between
the elipsis/diphthong and the next character.
This appears to be consistent both on-screen and when printed out, and
can usually be dealt with by adding a thin or en space after the
offending character, but it's not right.
We see it in different fonts, most notably recently Palatino (Adobe
font) and Goudy (Bitstream). We're using Type 1 fonts and the Adobe PS
driver to a PostScript printer (Canon 215).
Has anyone else seen this? Can anything be done? Is it Ventura or the
printer driver?
All help gratefully received.
John
--
Bookcraft Ltd
18 Kendrick Street, Stroud, Gloucestershire, England GL5 1AA
Tel: (+44) 870 160 1900
Fax: (+44) 870 160 1901
Website: www.bookcraft.co.uk
Jim Hart [C_Tech]
jo...@radical.demon.co.uk says...
|> We're using Type 1 fonts and the Adobe PS
|> driver to a PostScript printer
|>
What OS? What version of AdobePS?
|> Is it Ventura or the printer driver?
Or the font. The elipsis is a single character. Ventura gets
the metrics from the printer driver which gets them from the
.pfm file.
I use the elipsis a lot, and I used to use Palatino a lot. I
never had a problem with the elipsis overlapping the next
character, and I can't produce the problem now.
I just looked at Palatino in Fontographer and can see no
reason for any overlap to occur. The elipsis cell occupies a
full em (1000 units). The glyphs themselves occupy a total
of 784 units and are centered in the cell. so there is 108
units (.108 em) of space before the next cell.
If you would like to send a sample VP file and a PDF of the
output illustrating the problem, let me know and I'll give you
an ftp login and password on my server.
FWIW, the elipsis in a digital font probably does not occupy
as much space as was usual when set in metal. I had a client
that insisted I use <|>.<|>.<|>.<|> to set all elipsis. He
agreed this was too wide but insisted it was still more
accurate.
Alex Gray [C_Tech]
Ventura. We never got them to space correctly in Corel User, for example,
either when it used Frutiger 45 or when we moved to Charter.
Rather than analyse the situation exhaustively, we took the inelegant and
typographically inaccurate alternative of using three periods, and have had
no trouble since!
It's on my list of 'one day when I have time, I really must take a look at
why...'
--
Alex Gray [C_Tech]
Corel User magazine
www.coreluser.com
John Button
experiencing this problem.
But why? And has anybody got to the bottom of it?
Jim Hart [C_Tech]
mjpubli...@netscapeonline.co.uk says...
|> usually use
|> what your client insisted upon.
|>
|>
Except that is too wide. An ellipsis really should occupy 1.3
ems which is about half way between the width of the ellipsis
character and the width of the thin spaced periods.
mjpublications
what your client insisted upon.
Mike Jackson
Stephen Rodda
> Except that is too wide. An ellipsis really should occupy 1.3
> ems which is about half way between the width of the ellipsis
> character and the width of the thin spaced periods.
Agreed. I prefer to look upon the "ellipsis" character as tabular leader.
--
Stephen
The email address above is a spam trap.
com dot iname at sourceror (reversed) is my real email address.
mjpublications
Mike Jackson
Stephen Rodda
mjpubli...@netscapeonline.co.uk (mjpublications) wrote:
> Almost agreed! Hart's Rules for Compositors (the style guide for the
> OUP) specify three points separated by normal spaces. It would help if
> Ventura's thin space was thin.
Horace Hart is my constant companion.
Abe Hendin
>
> Almost agreed! Hart's Rules for Compositors (the style guide for the
> OUP) specify three points separated by normal spaces. It would help if
> Ventura's thin space was thin.
certainly not "thin"--I've found little if any difference between it and
a normal word-space at times when I really do need a difference, and I
wish things were different (and hope that changes could be made in the
next version).
Now--according to the Chicago Manual of Style, ellipsis points "are
usually separated from each other and from the text and any contiguous
punctuation by 3-to-em spaces" (10.62). As far as I know this is a
normal word-space, and the CMS glossary says that a thin space is
usually defined as 4-em, with a hair space being 5-em.
The problem with using a normal word-space between ellipsis points, of
course, is that in justified text the space between points will vary
widely depending on the variation in word-spacing required to maintain
the justified margins, which is why a thin-space is often used.
So--Hart's Rules ("three points separated by normal spaces") and CMS
would seem to agree, but a Ventura thin-space should in fact be LESS
than a normal space. So why, Mike, do you wish Ventura's thin-space were
thin for this purpose? (A thin-space being the minimum word spacing in
justified text.)
I personally wish we had precise control over such spaces--given the
precision at least theoretically obtainable in digital prepress, we
should be able to insert spaces of the exact width we need in any given
point size. Call it a horizontal advance, perhaps. After all, if we can
specify exact leading, why not exact horizontal spacing? When I need to
insert a space of exactly 2 points, I have to go through manual kerning
gyrations to get it, and it should be easier.
Abe
Stephen Rodda
Hendin) wrote:
> I personally wish we had precise control over such spaces--given the
> precision at least theoretically obtainable in digital prepress, we
> should be able to insert spaces of the exact width we need in any given
> point size.
I know such a solution isn't elegant, but I suppose one could always use
letters set in white. Yuk.
t.t.t. as an ellipsis. :)
Eric Weber [C_TECH]
>I definitely agree that Ventura's "thin space" is, unfortunately,
>certainly not "thin"--I've found little if any difference between it and
>a normal word-space at times when I really do need a difference, and I
>wish things were different (and hope that changes could be made in the
>next version).
Here's a quick and dirty workaround: You can create a character tag with only
kerning on it and apply it to a space to achieve any space width you desire.
-- Eric
[C_TECH Volunteer]
Paul McGee
comes out fatter than a regular space! This is obviously because the
"thin" space does not compress the way normal spaces do when justifying.
I can't think of a downside for having a thin space compress (only - not
expand) when used in justified text. (Obviously when a thin space is
required for alignment purposes, one would not be using justified
text.... unless VP ever catches up to Word Perfect in the use of tabs
within justified text, which, as anyone who has tried that, knows is not
remotely close to correctly implemented in VP8).
Perhaps a future release could implement another set of spaces (for all
the fixed spaces - em, en, thin) that would expand/compress the same as
the normal space when used in justified text, as the inverse problem
sometimes arises when spaces are stretched for justifying -- on rare
occasions I have seen lines where the normal spaces were larger than en
or even em spaces (yes, I know, a "loose" line - sometimes narrow
margins, a series of big words that just won't hyphenate at an
appropriate place, and text which absolutely requires a hard space (as
in 2 pounds) come up in catalogue work and my client(s) won't permit any
change in wording. Ugly but...)
Abe Hendin wrote: <snip>
>
> mjpublications wrote:
> >
> > Almost agreed! Hart's Rules for Compositors (the style guide for the
> > OUP) specify three points separated by normal spaces. It would help if
> > Ventura's thin space was thin.
>
Abe Hendin
> letters set in white. Yuk.
>
> t.t.t. as an ellipsis. :)
Agreed--YUK! Problem with this is that it would be a devil to
implement--selecting each "t" and applying an "invisible text" tag...or
creating a macro for it...
It's definitely a creative solution, though!
Abe
Abe Hendin
> Here's a quick and dirty workaround: You can create a character tag with only
> kerning on it and apply it to a space to achieve any space width you desire.
An interesting suggestion. I suppose one could create several different
character tags that each kerned a slightly different amount. What I'm
hoping, however, is that we don't have to go through these workarounds
and actually get fixed-width spaces in the variety we need in a
professional typesetting program.
Abe
Abe Hendin
> I can't think of a downside for having a thin space compress (only - not
> expand) when used in justified text. (Obviously when a thin space is
> required for alignment purposes, one would not be using justified
> text....
I absolutely don't want a thin space to compress, OR expand--it should
be a fixed-width value no matter what.
As for using it with alignment...in fact I have had occasion to use
spaces for alignment purposes in justified text when, for example, I get
a weird problem where italic text is too close to the following roman
text, despite a normal intervening space. I haven't been able to figure
out exactly the cause--it's not competing TT vs. T1 fonts as far as I
can tell--but I suspect it has to do with Ventura being overloaded with
huge footnotes it is told to place automatically. I don't think I've
seen the problem just yet in notes that I place manually.
Anyhow, it's in such a case (among others) that I need precision spacing
even in justified text--two spaces are just too much, two thin spaces
are just as excessive, as is an en space. Only appropriate solution is
to put the two spaces in and manually kern things a bit to achieve the
proper look. This is a workaround I'd rather not have to use, but given
that Ventura is pretty much incapable of dealing with lots of large
footnotes, and that's what I set, such workarounds are a fact of life
around here. And a precise horizontal advance feature would be useful in
many other contexts too (by "precise" I mean that I want to be able to
enter "2.75 pt", for example).
> unless VP ever catches up to Word Perfect in the use of tabs
> within justified text, which, as anyone who has tried that, knows is not
> remotely close to correctly implemented in VP8).
Nope, it sucks, and I'd like to see this better-implemented!
> occasions I have seen lines where the normal spaces were larger than en
> or even em spaces (yes, I know, a "loose" line - sometimes narrow
> margins, a series of big words that just won't hyphenate at an
> appropriate place, and text which absolutely requires a hard space (as
> in 2 pounds) come up in catalogue work and my client(s) won't permit any
> change in wording. Ugly but...)
But a hard space WILL expand or contract just like a normal space. Why
do you need a thin space, etc. to do this?
Abe
Paul McGee
can _usually_ be solved by including the trailing space *within* the
italic attribute. Almost always the problem arises because the italics
"lean" and the standard roman text in the next word does not. Including
the space in the italics makes VP think the lean continues so it adjusts
for it.
Abe Hendin wrote: <snips>
> As for using it with alignment...in fact I have had occasion to use
> spaces for alignment purposes in justified text when, for example, I get
> a weird problem where italic text is too close to the following roman
> text, despite a normal intervening space. I haven't been able to figure
> out exactly the cause--it's not competing TT vs. T1 fonts as far as I
> can tell.........
--------
Sure the hard space contracts/expands; that is not the problem here! My
reference to hard space was in keeping text together which in some work
has the extremely undesirable, but unfortunately necessary effect of
making justification of the line in question really ugly! So ugly that
when the line also contains em or en spaces up front, the normal spaces
become larger than the em or en spaces as a result.
For example, consider narrow margins and something along the lines of a
line containing a phrase such as this
<big words here, with an em space somewhere> width 36", length 78",
height 36", weight 412 pounds.
In this example it is mandatory to keep at least things like '412
pounds' together with a hard space; ideally all of "weight 412 pounds"
should be kept together on the same line. What I am saying is that this
invariably (don't know who's law that is! Boyle's, Charle's? oops, wrong
discipline) will give a line wrap with "412 pounds" going to the next
line and massive ordinary spaces in the first line. This often cause the
fixed <em> space in the text before this to be narrower than the
ordinary and non-breaking spaces in the line! Hence my case for having
another set of "variable fixed spaces" - an oxymoron if there ever was
one - that would contract and expand the same as ordinary spaces when
used in justified work. (I know my example is rather contrived, but
believe me, in catalogue work with small frames I really do encounter,
far too often, cases where a much wider than usual and non-breaking
(hence the "en" or "em" spaces) in a line that ends with a requirement
for a long string of text that must be on the same line. (Yes, somewhat
the same effect could be created by two hard spaces on a thin and a hard
or whatever, but these would be too big if the line was justified by
compression or moderate expansion of the spaces so each would have to be
handled individual base, frame by frame, change by change.)
BTW somewhere in the VP documentation ii defines the thin space as being
the width of a period. It did not say which kind of period (interpret
that however you want -- I didn't really say that but you can think I
did if you must) but it is the damned fattest period I have ever seen!
Jim Hart [C_Tech]
mjpubli...@netscapeonline.co.uk says...
|> It would help if Ventura's thin space was thin.
Yes, it would.
In Ventura 4.2 and earlier, in a paragraph with no letter
spacing, the width of the thin space is equal to the width of
a normal space. In a paragraph with letter spacing, the thin
space maintains the same value while the normal space is
adjusted according to the letterspacing.
In VP8, the width of the thin space is adjusted just like the
normal space is and since they start with the same value,
there is no effective difference.
I'm pretty sure this started in V7.
Abe Hendin
> The problem with italic text bumping into the non-italic words following
> can _usually_ be solved by including the trailing space *within* the
> italic attribute. Almost always the problem arises because the italics
> "lean" and the standard roman text in the next word does not. Including
> the space in the italics makes VP think the lean continues so it adjusts
> for it.
Thanks for the suggestion; I probably tried this and I doubt it
worked--the problem is not the general one of, say, a final italic "l"
leaning too close to e.g. an opening square bracket, or at all
consistent. Only on rare occasions do I have the problem, and many
instances in a particular para. are just fine, while that one...OY! So
it's an anomoly. I'll try including the trailing space in the italics
again next time the anomoly strikes, if I haven't already, and we'll
see.
Abe
Abe Hendin
> In VP8, the width of the thin space is adjusted just like the
> normal space is and since they start with the same value,
> there is no effective difference.
well, that's downright boneheaded! If it's called a thin space, why the
heck wasn't it designed as such according to general standards of
composition? Acc. to the manual it's supposed to be the width of a
period, but as you say it is more like a normal space--or at least a
wider period than I'VE ever seen!
This definitely needs to be on the agenda for Ventura improvement.
Abe
Abe Hendin
problem--I guess you want the em space to expand to the same degree as
the rest of the spaces, so that the em space STILL looks bigger than the
already ridiculously wide spaces caused by the pulling of big wwords to
the next line for justification purposes? I.e., if a normal space
expands by 250% to allow full justification, the em space also expands
250%?
I'm not sure this would be even a mildly unhappy solution. If things got
really ugly I might consider trying to get the boss to change the
catalog specs to left alligned!
Abe
Jim Hart [C_Tech]
a...@yourspeed.com says...
|> This definitely needs to be on the agenda for Ventura improvement.
|>
AFAIK, it has alwasy been on the list since the thin space has
never functioned in accordance with the definition. I know I
logged this at least once myself when I was still doing tech
support for Xerox.
The problem is that the thin space is defined as a space
the width of the period, but does not exist as a character in
th echaracter set. Therefore it is a calculated space. Now the
problem with calculating this space in accordance to the
definition is twofold:
1) The actual width of the period, both glyph and cell, vary
from face to face.
2) The width of the period glyph inside the charecter cell is
not available to VP8 unless VP8 accesses the font and font
metrics directly and reads the width of the glyph separately
from the width of the character cell.
As a result of 1), assigning an arbitrary value to the
thinspace will not be accurate for every face.
As a result of 2), Ventura would probably have to utilize a
completely different method of accessing font information than
it currently does. This would probably require that Ventura
bypass the OS and print drivers and calculate and store the
spacing information for both character cells and the glyphs
directly from the font itself.
Peior to V7, Ventura was halfway there through the use of
width tables, but it still did not have access to the glyph
size. The text formatting engine was completely reengineered
for V7 to avoid the need for width tables and use just the
font metric information accessible via calls to the OS and
printer driver.
IOW, another complete rewrite of the text formatter is
required, and it probably would mean a return to the use of
width tables in some form.
Abe Hendin
> The problem is that the thin space is defined as a space
> the width of the period, but does not exist as a character in
> th echaracter set. Therefore it is a calculated space. Now the
> problem with calculating this space in accordance to the
> definition is twofold:
Well, then. Why not do the following?
Ventura knows what the pt-size of the current para. font is, and it
knows what the width of an em space is for a given font. I just
confirmed that an em space in 72-pt type is way bigger than an em space
in 12-pt type. And there is no "em space" character, right?
So why can't Ventura forget completely about the variable size of a
period in various fonts, and calculate e.g. the thin space as 1/4 of an
em space, =2.5 pt in 10-pt type? I'd also like to see a hair space at 2
pt for 10-pt type, but what I'm really hoping for is a simple verticle
advance feature along the lines of the "add width of preceding line"
option in the para. alignment dialog. Ventura already knows how to
calculate this, and can take the width of the preceding line value and
add X.X pts to it, resulting in exactly X.X pts of space between the
last char of this preceding line and the first character of the next
line. It shouldn't be such a hard step to apply the anchor point to any
character and allow us to specify what I'm calling a horizontal advance,
i.e. the equivalent of the "line indent amount" setting from the para.
props. dialog. Or at least to divide the em space (i.e. point-size of
the current font) by 4 or 5 and insert a thin or hair space the width of
which is the resulting point value.
Abe
Jim Hart [C_Tech]
says...
|> So why can't Ventura forget completely about the variable size of a
|> period in various fonts, and calculate e.g. the thin space as 1/4 of an
|> em space, =2.5 pt in 10-pt type?
|>
IOW, change the definition of a thin space? I've seen thin
space variously defined as the width of a period, 1/5 of an
em, 1/4 of an em... Any one of them could be used but accuracy
would still be a matter of opinion. But it requires a decision
and that requires someone to make it.
Abe Hendin
> In fact, I have found that a safer way to control spaces in fine divisions
> is to control the font size of the space characters. To use this, you must
> have grow interline to fit switched off (I always do, so it isn't a hardship
> for me).
I don't really need interline to fit on either--actually bugged me
periodically before I switched it off. Thanks for the suggestion, Alex,
it may be the best one yet and is one I hadn't even considered. Since
Ventura appears to calculate the em space based on the font size as it
should, I should theoretically be able to get my precise space just by
entering an em space, then setting its font size to the exact width
space I need--so if I need a thin space at 2.5 pt for a 10-pt font, I'd
set the font size of my em space to 2.5 pt., which should theoretically
yield a 2.5-pt space. I'll play around and see what turns up.
Abe
Jim Hart [C_Tech]
|> What is odd is that in most modern fonts,
|> the ellipsis character(Alt+0133) is spaced way too tight for either of
|> these, being usually equivalent to three periods with no extra spacing.
|>
|>
In most modern (digital) fonts, the ellipsis is the same width
as an em-space. This makes some kind of sense in that the base
character cell for a digital font is 1 em.
Abe Hendin
> Ellipsis in the Chicago manual is points separated by em/3 as you say. This
> is what was called a thick space or 32 units on the old Monotype 96-unit
> scale.
>
> Whereas Hart has them separated by a 'normal' or 'middle' space, which is
> em/4 (24-units).
Ahh, not being a buff I didn't realize that the two manuals were working
with different size spaces.
> What is odd is that in most modern fonts,
> the ellipsis character(Alt+0133) is spaced way too tight for either of
> these, being usually equivalent to three periods with no extra spacing.
Yes, I don't understand whty the heck it's there in the first place. Who
the heck designs these things, anyway?
>
> > The problem with using a normal word-space between ellipsis points, of
> > course, is that in justified text the space between points will vary
> > widely depending on the variation in word-spacing required to maintain
> > the justified margins, which is why a thin-space is often used.
>
> > So--Hart's Rules ("three points separated by normal spaces") and CMS
> > would seem to agree, but a Ventura thin-space should in fact be LESS
> > than a normal space. So why, Mike, do you wish Ventura's thin-space were
> > thin for this purpose? (A thin-space being the minimum word spacing in
> > justified text.)
>
> You've argued yourself in a circle here! It is true that Ventura's so-called
> thin space is in fact a fixed width 'normal' space, which may be a daft
> situation, but it does at least mean that it is ideal for spacing out
> ellipsis periods! Also it is non-breaking by default. So that is why Mike
> would wish to use it, I guess.
I don't *think* I've argued myself into a circle, at least not based on
my former (mis)understanding in thinking Hart's Rules and CMS were in
sync. In other words, if CMS wants a 3-to-em space between ellipsis
dots, and Ventura's thin space is equivalent to a 3-to-em space, why
does Mike want a space thinner than 3-to-em for his ellipsis dots? Now
it turns out that Hart's Rules is different from CMS, and wants a
4-to-em space between the dots, and I can understand why Mike, if
following Hart's Rules, wants Ventura's thin space to actually be
4-to-em. Which is what the damn thing ought to be in the first place!
> the figure shown as 'Normal space width'
> in the typography dialogue of a paragraph
What's this? I haven't seen it.
> I foresee big trouble if Corel were to correct it to a more conventional
> thin space definition, since there would be an 'orrible issue of backward
> compatibility. It would at least need a publication-based preference switch
> as Corel introduced when they corrected the omission of non-breaking
> attributes on fixed spaces.
Agreed. But a publication-based preference switch shouldn't be TOO hard
to apply, no? It seems clear that Ventura's definition of a thin space
is clearly at variance with older standards of composition.
> The universal solution would be to have a special horizontal space
> 'character' that has a user-specifiable width. But, that alone is not
> enough - the properties for this symbol must allow one to specify whether is
> absolutely fixed, or fixed relative to the current point size. And beyond
> that, whether it should obey or ignore any tracking or kerning settings in
> effect.
So just add a couple switches and you're good to go! Ventura currently
calculates the em space based on font size, and I see no reason not to
have a set of spaces that operate the same way but are called 4-to-em or
5-to-em, etc. But yes, I'm looking for the perfect solution that allows
me to specify an exact point-value for the width of a space. It could
have the same options as for space above and below, and leading, that
are on the space tab of para. props.--there you can choose to allow
percentage adjustment in case you decide in the middle of work to change
the specs and don't want to have to redjust all your leading etc.
manually, or set the values to remain fixed. This would be an ideal
situation here too, I suspect.
> This could get out of hand!
Things could indeed, but as they are now we simply do not have the
control over horizontal spaces that we should. Here in the age of
computers we don't even have the control we would've had were we using
metal type in this case! Forget about decimals. The composition world
operates in points, it seems, and this is plenty fine a measure for this
purpose. Just make sure you can specify the standard Ventura distinction
of hundredths of points and that's as much precision as will be needed.
It seems to me that we've come up with enough possibilities to go to the
prodman with this thread and urge Corel to come up with something
workable that won't screw everyone who got their pubs. right using
bass-ackward thin spaces all these years!
Abe
Abe Hendin
> IOW, change the definition of a thin space? I've seen thin
> space variously defined as the width of a period, 1/5 of an
> em, 1/4 of an em... Any one of them could be used but accuracy
> would still be a matter of opinion. But it requires a decision
> and that requires someone to make it.
Good point. But if a thin space is the thinnest space Ventura can give
us, and it's the same width as a normal space, then it's not helpful
except where you need a fixed-width normal space--and it's therefore
mis-named. The ideal, as has been discussed elsewhere in this thread,
would be to have a mechanism to specify a precise point-value for the
width of a spacer of some sort.
Alex Gray [C_Tech]
> Here's a quick and dirty workaround: You can create a character tag with
only
> kerning on it and apply it to a space to achieve any space width you
desire.
Very dangerous ground that, Eric. For one thing, normal spaces don't obey
'kerning' if they are in justified paras.
In fact, the handling of spaces, both the so-called fixed spaces and the
'ordinary' spaces in the face of kerning and tracking is truly weird in
Ventura.
In an unjustified (ie flush left) paragraph, all spaces respond to tracking
settings, but 'fixed' spaces do not obey kerning. And since ventura tracks
by moving each symbol closer to the previous one by a fixed amount, the
en-space, for example, is reduced by a greater proportion than the em space
if tracking is applied.
In a justified paragraph, so called 'fixed spaces' honour the tracking
settings, but 'ordinary' spaces don't. Nor do they honour kerning settings.
All very difficult to keep in mind when fiddling with these things.
In fact, I have found that a safer way to control spaces in fine divisions
is to control the font size of the space characters. To use this, you must
have grow interline to fit switched off (I always do, so it isn't a hardship
for me).
Alex
Alex Gray [C_Tech]
I don't worry about it - the ellipsis symbol in almost all fonts is way to
tightly set according to the suggestions of most typographic references
(such as Hart's rules). If you want to follow them, the best option is three
periods separated by Ventura thin spaces (which are actually fixed width
normal spaces).
Alex
Alex Gray [C_Tech]
> Now--according to the Chicago Manual of Style, ellipsis points "are
> usually separated from each other and from the text and any contiguous
> punctuation by 3-to-em spaces" (10.62). As far as I know this is a
> normal word-space, and the CMS glossary says that a thin space is
> usually defined as 4-em, with a hair space being 5-em.
Hart's rules (which we also use generally) are at variance with the Chicago
manual over the ellipsis.
Ellipsis in the Chicago manual is points separated by em/3 as you say. This
is what was called a thick space or 32 units on the old Monotype 96-unit
scale.
Whereas Hart has them separated by a 'normal' or 'middle' space, which is
em/4 (24-units).
This difference is not surprising. What is odd is that in most modern fonts,
the ellipsis character(Alt+0133) is spaced way too tight for either of
these, being usually equivalent to three periods with no extra spacing.
> The problem with using a normal word-space between ellipsis points, of
> course, is that in justified text the space between points will vary
> widely depending on the variation in word-spacing required to maintain
> the justified margins, which is why a thin-space is often used.
> So--Hart's Rules ("three points separated by normal spaces") and CMS
> would seem to agree, but a Ventura thin-space should in fact be LESS
> than a normal space. So why, Mike, do you wish Ventura's thin-space were
> thin for this purpose? (A thin-space being the minimum word spacing in
> justified text.)
You've argued yourself in a circle here! It is true that Ventura's so-called
thin space is in fact a fixed width 'normal' space, which may be a daft
situation, but it does at least mean that it is ideal for spacing out
ellipsis periods! Also it is non-breaking by default. So that is why Mike
would wish to use it, I guess.
Maybe it *should* be less than a normal space, but since it isn't, we may as
well use it for what it is. It's been this way for many versions now.
Ventura defines it as the width of a period (including the period's built in
spacing), which also happens to be the same as a normal unjustified space.
Actually, I've always suspected, but never checked, that Ventura derives it
'normal' space width from the width of a period in a given font (including
its sidebearings), because a little experimentation will soon show you that
it doesn't appear to correspond to the figure shown as 'Normal space width'
in the typography dialogue of a paragraph, even allowig for tracking, but it
does always appear the same width as a period.
I foresee big trouble if Corel were to correct it to a more conventional
thin space definition, since there would be an 'orrible issue of backward
compatibility. It would at least need a publication-based preference switch
as Corel introduced when they corrected the omission of non-breaking
attributes on fixed spaces.
>
> I personally wish we had precise control over such spaces--given the
> precision at least theoretically obtainable in digital prepress, we
> should be able to insert spaces of the exact width we need in any given
> point size. Call it a horizontal advance, perhaps. After all, if we can
> specify exact leading, why not exact horizontal spacing? When I need to
> insert a space of exactly 2 points, I have to go through manual kerning
> gyrations to get it, and it should be easier.
The universal solution would be to have a special horizontal space
'character' that has a user-specifiable width. But, that alone is not
enough - the properties for this symbol must allow one to specify whether is
absolutely fixed, or fixed relative to the current point size. And beyond
that, whether it should obey or ignore any tracking or kerning settings in
effect.
Only with those options can one set up any required spacing and be sure it
will behave as required if, for example, all the fonts used are scaled up or
down, or a paragraph is tracked tighter, for example.
Using these spaces would need some care! Maybe another simple option would
be to have a set of absolute fixed spaces (1, 2, 4, 8, 16, 32pt), and a set
of point-size related fixed spaces (em/96, em/48, em/24, em/8, em/5 aka
thin, em/4 aka normal, em/2 aka en-space). With these, any required size
could be set by a combination.
Of course, then you might also want a metric set (.25mm, .5mm, 1mm, 2mm,
4mm, 8mm for example).
This could get out of hand!
Alex
John Button
Plus, this might deal with the ellipsis problem, but it doesn't deal
with the diphthong problem. You can't deal with the oe and ae diphthongs
this way.
--
Bookcraft Ltd
18 Kendrick Street, Stroud, Gloucestershire, England GL5 1AA
Tel: (+44) 870 160 1900
Fax: (+44) 870 160 1901
Website: www.bookcraft.co.uk
Jim Hart [C_Tech]
jo...@radical.demon.co.uk says...
|> Plus, this might deal with the ellipsis problem, but it doesn't deal
|> with the diphthong problem. You can't deal with the oe and ae diphthongs
|> this way.
|>
John,
Since you started this thread, I have been looking at the
ellipsis (a lot) and trying to duplicate your complaint. So
far, I've had no luck and I don't want your original complaint
to get lost in the search for the perfect thin space.
We do know that the ellipsis in any digital font is probably
not going to be typographically correct according to standard
style manuals, being 1 em in width instead of the roughly 1.4
- 2.1 em recommended. But this still does not cause the
ellipsis to overlap the following character. Same with the
diphthongs. I don't see any overlap unless I adjust the
tracking/kerning values to create the overlap.
Franca Voegelin [C_Tech]
> ellipsis to overlap the following character. Same with the
> diphthongs. I don't see any overlap unless I adjust the
> tracking/kerning values to create the overlap.
I haven't tried diphthongs but I'm having no trouble with the ellipsis
here either. No overlap with subsequent text.
Stephen Rodda
> This makes some kind of sense in that the base
> character cell for a digital font is 1 em.
Not really, because there are ligatures, decorations and digraphs which
are larger.
John Button
Isn't it annoying when you have a problem that others can't duplicate!
Jim, I'll take you up on your offer to look at a sample file as soon as
I have a moment. Feels like it must be the printer driver, but it'll be
interesting to see if you can duplicate the problem with our file.
best
John
Paul McGee
than justified text with large gaps in a catalogue full of 2-1/2 inch
wide boxed frames is ragged text on the same sized boxed frames. At
least justified text in these cases maintains some semblance of visual
continuity. Interletter justification, quite well implemented in VP, if
not abused, helps a bit in some of these cases, but the best one can
hope for is that it will be "less ugly".
(Boy the stories I could tell about justification in some of the older
word processors -- such as one that insisted under some circumstances on
justifying the last line, even if it consisted of one two letter word
and a period!!! We don't really want to recall those days do we?)
Abe Hendin wrote: <snip>
Abe Hendin
> (Boy the stories I could tell about justification in some of the older
> word processors -- such as one that insisted under some circumstances on
> justifying the last line, even if it consisted of one two letter word
> and a period!!! We don't really want to recall those days do we?)
True enough, Paul! Those were primitive days indeed. And if your catalog
would be even uglier with right-justified text, I don't envy you. It's
no fun setting something so it is merely "less ugly". In some cases
one's policy has to be reduced to "as good as it can get"--and as long
as the client finds the result acceptable, we can stay in business.
Abe
Jim Hart [C_Tech]
postm...@dood.nl.eu.org says...
|> Not really, because there are ligatures, decorations and digraphs which
|> are larger.
|>
I didn't say it made complete sense. <g>
There are exceptions of course as expnaded/extended faces are
normally wider than 1 em.
I think it probable that someone, somewhere decided that there
was no good reason for the ellipsis to be so wide and designed
a smaller one. MAybe soneone at Adobe. After all, they changed
the value of the point when they created Postscript. 8^)
Jim Hart [C_Tech]
jo...@radical.demon.co.uk says...
|> Feels like it must be the printer driver,
|>
That is my suspicion. Are you using Win9x or NT?
Paul McGee
regularly (think it was called something like "Font & Design" - I still
have it somewhere but in one of my (in)famous piles here or at home)
that had a feature about true typesetting with the marvellous Adobe
fonts. One of the items had them saying (approximate wording) "never use
3 periods for the ellipsis. That is typewriting. The [Adobe] ellipsis is
optimally designed to be seen as one item."
(BTW a different issue of the same publication had a multi-page article
devoted exclusively to the Ampersand! Adobe do "think different"
indeed.)
If I stumble over one of my "piles" in the near future and the article
pops up, I will be more precise, but it does seem that the current
excessively compressed (by the standards quoted in this thread) is
indeed an Adobe "pride and joy" specification.
Abe Hendin
> it does seem that the current
> excessively compressed (by the standards quoted in this thread) is
> indeed an Adobe "pride and joy" specification.
And therefore utterly spurious. At least there was a certain amount of
logic in changing the size of the point from .013755158" to .013888888
in. to round off to 72 points per inch, even if it did lose 1.33722
ten-thousandths of an inch! (Man, I've been crying ever since...)
Their version of ellipsis dots just plain looks bad.
Abe
Stephen Rodda
> MAybe soneone at Adobe. After all, they changed
> the value of the point when they created Postscript. 8^)
Indeed.
Abe Hendin
> Simply because I would like my elipsis to be slightly tighter than
> recommended by Hart's Rules (Mike's Rules :-) )
Gotcha!
mjpublications
Simply because I would like my elipsis to be slightly tighter than
the elipsis character. If Ventura's thin space was correctly implemented it
may be wrong for an elipsis, I don't know. I do know that Corel's idea of a
thin space is not mine. Actually, I'm reasonably happy with the elipsis
formed with V's thin spaces, at least the spaces don't expand or contract in
justified text.
Mike
John Button
Jim Hart [C_Tech]
jo...@radical.demon.co.uk says...
|> NT4 service pack 4
|>
Well, that eliminates one potential source.
Alex Gray [C_Tech]
> I don't really need interline to fit on either--actually bugged me
> periodically before I switched it off. Thanks for the suggestion, Alex,
> it may be the best one yet and is one I hadn't even considered. Since
> Ventura appears to calculate the em space based on the font size as it
> should, I should theoretically be able to get my precise space just by
> entering an em space, then setting its font size to the exact width
> space I need--so if I need a thin space at 2.5 pt for a 10-pt font, I'd
> set the font size of my em space to 2.5 pt., which should theoretically
> yield a 2.5-pt space. I'll play around and see what turns up.
Exactly so, except for one gotcha...
Ventura does indeed base the em-space on a traditional 'em-quad' - its
overall width is exactly the same as the nominal point size. However, it
also subjects the so-called 'fixed-spaces' to the tracking value of a
paragraph. By default tracking is set to 'normal', which is based on using
the font's nominal spacing values at 12pt, but tracking characters closer
together at larger sizes, and further apart at smaller sizes.
With normal tracking, Ventura adds or subtracts a certain percentage of the
point size from the inter-character space of all characters, including fixed
spaces. The amount varies on a logarithmic scale from about +.023em looser
at 3pt, through nominal spacing at 12pt, 0.031em tighter at 48pt, and so on
up.
So if you leave normal tracking applied to a paragraph you need to allow for
this effect. For example, an em-space in a 72pt normally tracked font is
actually about 69pt (ie 0.042em narrower).
If you want more control of this, you can use custom tracking so you know
what correction to apply.
If you are using em-spaces in 10pt text, you might for the sake of an easy
life set the tracking to Custom 0.0, which would mean that a 2.5pt em-space
would be 2.5pt wide. The text would look a touch tighter than the 'Normal'
tracking as Ventura would normally apply about 0.3pt tightening to the
inter-letter space at 10pt, but you may not notice (or may even prefer) the
very slightly wider setting.
Alex Gray [C_Tech]
Corel User
www.coreluser.com
Ed Brown
Abe Hendin
> If you are using em-spaces in 10pt text, you might for the sake of an easy
> life set the tracking to Custom 0.0, which would mean that a 2.5pt em-space
> would be 2.5pt wide. The text would look a touch tighter than the 'Normal'
> tracking as Ventura would normally apply about 0.3pt tightening to the
> inter-letter space at 10pt, but you may not notice (or may even prefer) the
> very slightly wider setting.
Thanks for the tip, Alex. I assume you mean that the "text would look a
touch looser" if I were to set the tracking to 0 at 10 pt?
My relevant math skills being so rusty, I was just about to ask how I'd
calculate the precise addition or subtraction in points that Ventura
would apply to an em space, when I discovered that my character tracking
is already set to Custom 0.0 already--this seems to be the Ventura
default, cuz it's in my default pub which I don't *think* I've modified.
hmmm. well, since I didn't bother with setting this, now I wonder how
things would look if I set it to "normal"! A project for another time.
Abe