That's really cool! I've always been interested in improving the plain,
flat-faced appearance of text. Your results are very impressive.

Regards,
Dave Blandston

Post a reply to this message

"Dave Blandston" <nomail@nomail> wrote:
> That's really cool! I've always been interested in improving the plain,
> flat-faced appearance of text. Your results are very impressive.
>
> Regards,
> Dave Blandston

As are your bordered chars, which of course prompted to post my nearly
orthogonal system.

I'll have to look at how you kern. I gave up on automatic kerning. I thought I
would need to populate an nxn matrix where n is the number of characters. I'll
also have to think about justifying paragraphs.

Thanks for the impetus to finally post something.

Jim T.

Post a reply to this message

On 07/12/2016 12:31 PM, JimT a dit:
> "JimT" <nomail@nomail> wrote:
> Gauss' and Stokes' theorems, with edge highlights.
>
    Did you really work on a LaTeX plugin for POVray ?

-- 
http://weblog.mixart-myrys.org/?post/2016/03/De-la-temporalisation

Post a reply to this message

"JimT" <nomail@nomail> wrote:
> I'll have to look at how you kern. I gave up on automatic kerning. I thought I
> would need to populate an nxn matrix where n is the number of characters. I'll
> also have to think about justifying paragraphs.
>
> Thanks for the impetus to finally post something.
>
> Jim T.

I did make an nxn table of kerning values. There are 82 characters in my
character set so it took a long time to do by hand. Later I did think of a way
to automatically generate the kerning values. Unfortunately, the method I
thought of relied on CSG intersections and the min_extent () and max_extent ()
functions. It did not work properly. I consulted the documentation and found the
following message regarding these functions:

Note: This is not perfect, in some cases (such as CSG intersections and
differences or isosurfaces) the bounding box does not represent the actual
dimensions of the object.

So if you can fix POV-Ray's min_extent () and max_extent () functions to work
with CSG intersections or think of a work-around, here's a macro to compute
kerning values. Good luck!

Regards,
Dave Blandston

Post a reply to this message

Attachments:
Download 'kerning.zip' (3 KB)

Oops, in that last post I left a file out that's necessary to use the manual
kerning method. I doubt anyone would ever actually use it, but here it is just
in case...

Regards,
Dave Blandston

Post a reply to this message

Attachments:
Download 'kerning.zip' (3 KB)

Am 16.07.2016 um 15:28 schrieb Dave Blandston:

> So if you can fix POV-Ray's min_extent () and max_extent () functions to work
> with CSG intersections or think of a work-around, here's a macro to compute
> kerning values. Good luck!

Talking of "fixing" the functions is a bit off the mark: They're not
broken; they're specified to give you the coordinates of the bounding
box, and that's exactly what they do. The auto-computed bounding boxes,
in turn, do not have to be perfect -- and for fundamental reasons cannot
be. All that's necessary for bounding boxes is that they are guaranteed
to include the entire object, while still being reasonably small.

Given the vast palette of geometric primitives supported by POV-Ray,
computing the exact extensions of an arbitrary CSG intersection or
difference is in fact a "hard problem" -- in the technical sense as used
in informatics. Meaning "practically impossible".

Algorithms to compute approximations are feasible, but come with the
risk of giving erroneous results, computing dimensions that fail to
include the entire object, which is a no-go for bounding boxes.

Post a reply to this message

"Dave Blandston" <nomail@nomail> wrote:

> So if you can [...] think of a work-around, here's a macro to compute
> kerning values. Good luck!

Hi Dave,
I haven't had the time yet to dig into your extensive set of complicated macros
:O  You have accomplished a great deal in this Herculean task!

Do you think you could use trace() to find the exact points that you need?

Perhaps "scan" down the side of a letter with a loop and overwrite a vector
variable with a new value any time the trace() dimension is smaller / larger
than the last value stored.

Then you could sort of roll your own bounding box(es).

Maybe couple subdividing the letters with this strategy to get bounding boxes of
specific sections of the letters.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 16.07.2016 um 15:28 schrieb Dave Blandston:
>
> > So if you can fix POV-Ray's min_extent () and max_extent () functions to work
> > with CSG intersections or think of a work-around, here's a macro to compute
> > kerning values. Good luck!
>
> Talking of "fixing" the functions is a bit off the mark: They're not
> broken; they're specified to give you the coordinates of the bounding
> box, and that's exactly what they do. The auto-computed bounding boxes,
> in turn, do not have to be perfect -- and for fundamental reasons cannot
> be. All that's necessary for bounding boxes is that they are guaranteed
> to include the entire object, while still being reasonably small.
>
> Given the vast palette of geometric primitives supported by POV-Ray,
> computing the exact extensions of an arbitrary CSG intersection or
> difference is in fact a "hard problem" -- in the technical sense as used
> in informatics. Meaning "practically impossible".
>
> Algorithms to compute approximations are feasible, but come with the
> risk of giving erroneous results, computing dimensions that fail to
> include the entire object, which is a no-go for bounding boxes.

Please forgive my poor word choice. That kind of programming is way beyond my
meager capabilities. Thanks for explaining it though.

Regards,
Dave Blandston

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Hi Dave,
> I haven't had the time yet to dig into your extensive set of complicated macros
> :O  You have accomplished a great deal in this Herculean task!
>
> Do you think you could use trace() to find the exact points that you need?
>
> Perhaps "scan" down the side of a letter with a loop and overwrite a vector
> variable with a new value any time the trace() dimension is smaller / larger
> than the last value stored.
>
> Then you could sort of roll your own bounding box(es).
>
> Maybe couple subdividing the letters with this strategy to get bounding boxes of
> specific sections of the letters.

That sounds promising... I've never used the trace () feature before so when I
get some free time I'll give it a try. From what you're describing that would
provide the functionality I'm looking for (and could help Jim T. out). Thanks
for the suggestion!

Regards,
Dave Blandston

Post a reply to this message

"JimT" <nomail@nomail> wrote:
> I'll have to look at how you kern. I gave up on automatic kerning. I thought I
> would need to populate an nxn matrix where n is the number of characters. I'll
> also have to think about justifying paragraphs.

The automatic kerning method that Bald Eagle suggested in this very thread does
indeed work very well. Thank you Bald Eagle! I will post a demo in the scene
files area.

JimT, this is what I recommend for your purposes if you choose to use the macros
I will post: Do not create an nxn matrix of kerning values. Your character set
is too large. Use the ComputeKerningValue () macro as needed throughout your
scene. You will have to change some variable names to match your scene.

The AutomaticKerningDemo.pov file is set up to work just as described above.

You may need to do some preparatory steps on your own... The macros require an
array that contains the widths of all your characters. You may be able to use
max_extent () to compute the widths. If not, you can adapt the MeasureCharacter
() macro for this purpose.

When you run the AutomaticKerningDemo.pov file, take a look at the "Messages"
tab for the output.

Regards,
Dave Blandston

Post a reply to this message