 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Due to a limitation (not a bug) in the Circle_Text macro in shapes.inc, the
spacing for text created with the Circle_Text macro is not optimal.
Rendering the code at the end of this message will demonstrate it.
Again, it's not a bug, so it's not something that's easy to fix, but perhaps
someone can come up with a solution anyway? There's a challenge for you! ;)
// Upper text has spacing by Cirle_Text macro.
// Lower text is a regular text object with correct spacing.
#include "shapes.inc"
camera {location -1.4*z orthographic}
background {color rgb 1}
#declare String = "AV-VELVA-V"
object {
Circle_Text("maiandb.ttf",String,0.45,0.01,50,0,3,+90)
translate -49.8*y pigment {color rgb 0}
}
#declare Text = text {ttf "maiandb.ttf",String, 0.01, 0}
object {
Text
translate -(min_extent(Text)+max_extent(Text))/2
scale 0.45 pigment {color rgb 0}
}
Rune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 22 Oct 2001 23:14:39 +0200, Rune wrote:
> Due to a limitation (not a bug) in the Circle_Text macro in shapes.inc, the
> spacing for text created with the Circle_Text macro is not optimal.
> Rendering the code at the end of this message will demonstrate it.
>
> Again, it's not a bug, so it's not something that's easy to fix, but perhaps
> someone can come up with a solution anyway? There's a challenge for you! ;)
Aw, c'mon, the challenge is getting Circle_Text back into a human-readable
form, isn't it?
It's certainly possible to take kerning into account when calculating the
letter spacings; I've written macros to do that. The problem is that once
you start letting the space for a letter overlap the space for another letter,
you can end up with actual glyphs overlapping after you bend them around
the circle.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" wrote:
> Aw, c'mon, the challenge is getting Circle_Text
> back into a human-readable form, isn't it?
Yeah, but I didn't want to put it that way. ;)
Wait a minute - you wrote it!
> It's certainly possible to take kerning into account
> when calculating the letter spacings; I've written
> macros to do that.
So now you have a moral obligation to fix the problem.
> The problem is that once you start letting the space
> for a letter overlap the space for another letter,
> you can end up with actual glyphs overlapping after
> you bend them around the circle.
I would like to introduce a new input variable where the user can add space
between the letters. Actually I'm surprised it isn't already there, as it's
a rather basic thing that can also be used just as a part of the text
design.
If you could fix these things it'd be a great improvement of the macro!
Please? :)
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's certainly possible to take kerning into account when calculating the
> letter spacings; I've written macros to do that. The problem is that once
> you start letting the space for a letter overlap the space for another
letter,
> you can end up with actual glyphs overlapping after you bend them around
> the circle.
Actually, I don't think they will, as long as you're bending in such a way
that the distance between points never decreases. Otherwise the glyphs would
be overlapping anyway, regardless of kerning.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Rune who wrote:
>Due to a limitation (not a bug) in the Circle_Text macro in shapes.inc, the
>spacing for text created with the Circle_Text macro is not optimal.
>Rendering the code at the end of this message will demonstrate it.
>
>Again, it's not a bug, so it's not something that's easy to fix, but perhaps
>someone can come up with a solution anyway? There's a challenge for you! ;)
The obvious fix is to replace
#if(CI != 1)
#local LW = TextWidth(F, substr(T,1,CI-1), S);
#else
#local LW = 0;
#end
#local OE = TextWidth(F, substr(T,CI,1), S);
by
#local OE = TextWidth(F, substr(T,CI,1), S);
#local LW = TextWidth(F, substr(T,1,CI), S) - OE;
thus including the kerning of the current letter in the positioning
calculation, rather then just the kerning of the previous letters in the
string.
I don't have the maiandb.ttf font on my machine, but with other fonts,
the two lines in your example file look identical with that change.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mike Williams" wrote:
> thus including the kerning of the current letter in
> the positioning calculation, rather then just the
> kerning of the previous letters in the string.
Thanks!
> I don't have the maiandb.ttf font on my machine, but
> with other fonts, the two lines in your example file
> look identical with that change.
It sure is much better, but not exactly identical. Try the following code:
// Upper text has spacing by Cirle_Text macro.
// Lower text is a regular text object with correct spacing.
#include "shapes.inc"
camera {location -z orthographic}
background {color rgb 1}
#declare String = "AE-EO-A"
#declare Font = "cyrvetic.ttf"
object {
Circle_Text(Font,String,0.45,0.5,0.01,50,0,3,+90)
translate -49.8*y pigment {color rgb 0}
}
#declare Text = text {ttf Font,String, 0.01, 0}
object {
Text
translate -(min_extent(Text)+max_extent(Text))/2
scale <1,-1,1> scale 0.45 pigment {color rgb 0}
}
But it's not a big problem.
You seem to understand the macro well, so could you possible do another
change to it?
I'd like to have a spacing option added that works like the x component of
the offset vector in regular fonts in POV-Ray.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Rune who wrote:
>"Mike Williams" wrote:
>> thus including the kerning of the current letter in
>> the positioning calculation, rather then just the
>> kerning of the previous letters in the string.
>
>Thanks!
>
>> I don't have the maiandb.ttf font on my machine, but
>> with other fonts, the two lines in your example file
>> look identical with that change.
>
>It sure is much better, but not exactly identical. Try the following code:
That effect seems to be being caused by something strange in the
behaviour of the TextWidth() macro.
If we rip out the "|" characters from the TextWidth() macro, like this:-
#macro TextWidth(Font, Text, Size)
#local TO = text {ttf Font Text 1 0 scale <Size,Size,1>}
((max_extent(TO).x-min_extent(TO).x))
#end
Together with my previous change, it looks a bit better.
In case anyone out there is using TextWidth() directly in their scenes,
it might be better to give my simplified version a different name and
use that throughout Circle_Text().
My version returns just the width of the string (which is what we now
need in the version of Circle_Text with corrected kerning). The current
TextWidth() returns the width of the string plus possibly some extra
space at the ends.
> You seem to understand the macro well, so could you possible do
> another change to it?
> I'd like to have a spacing option added that works like the x
> component of the offset vector in regular fonts in POV-Ray.
That's easy. Just pass that value into the Circle_Text() macro, and pass
it forward into the (new) TextWidth() macro and use it as the x
component of the offset vector in the local text object, like this:-
#macro TextWidth(Font, Text, Size, Offset)
#local TO = text {ttf Font Text 1 Offset*x scale <Size,Size,1>}
((max_extent(TO).x-min_extent(TO).x))
#end
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mike Williams" wrote:
> If we rip out the "|" characters from the TextWidth() macro,
> Together with my previous change, it looks a bit better.
This works perfectly, and so does the spacing option! Thanks!
> In case anyone out there is using TextWidth() directly in
> their scenes, it might be better to give my simplified
> version a different name and use that throughout Circle_Text().
I'm not sure, but I don't really see a reason to preserve the old TextWidth
macro. What can it be used for? You've proved that even the Circle_Text
macro for which it was probably designed works better with the new version,
which is also much simpler. I think I'll simply replace the old TextWidth
macro with the new one (and of course change the comments and documentation
accordingly).
> The current TextWidth() returns the width of the string plus
> possibly some extra space at the ends.
And I haven't yet seen an example where this was in fact needed.
BTW, the comments for Circle_Text says:
"Angle: The point on the circle from which rendering will begin.
The +x direction is 0 and the +y direction is 90 (i.e. this is a
RIGHT HANDED coordinate system."
Does it make sense to talk about a right-handed coordinate system here? I
think not. I'll rephrase it to:
"Angle: The point on the circle from which rendering will begin.
The +x direction is 0 and the +y direction is 90 (i.e. the angle
increases anti-clockwise."
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 24 Oct 2001 14:38:00 +0200, Rune wrote:
> I'm not sure, but I don't really see a reason to preserve the old TextWidth
> macro. What can it be used for?
It's most useful for finding the width of a string if you plan to append
it to another string.
The problem with doing it without the extra space is that you then get the
exact width of the text, right to the right edge of the last character. So
if you do
#declare T1=text{ttf "arial.ttf", "Normal" .001 0}
#declare T2=text{ttf "arialbd.ttf", "Bold" .001 0}
union {
object{T1}
object {T2 translate x*(max_extent(T1)-min_extent(T1))}
texture {pigment {color rgb 1} finish {ambient .5}}
}
camera {location -10*z look_at 0}
you find that the "B" in "Bold" is butted right up against the "l" in
"Normal". (since TextWidth without the bars is just what I've used there.)
A character has an intrinsic property known as "advance width" which is
not at all related to the width of the actual glyph. The easy example is
a plain space: the glyph has no width at all, but the advance width is
about the same as the advance width of an 'n'. Another easy example is
a nonproportional font: the W is a lot wider than the l, but they both have
the same advance width.
min_extent/max_extent can only extract the glyph width, but by adding on
the vertical bars and taking the width of that, then subtracting the width
of the vertical bars by themselves, you should get the advance widths of
all the characters in the string.
The problem you're seeing might be that some characters actually get
kerned against the "|" character, which would screw up the advance width
calculation. There's no easy way to fix this. In fact, I picked "|"
because it's one of the least likely characters to be kerned.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
