This is pretty much the same as the alpha just published, but with the 
new `text` handling.


https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.4

Differences to the Alpha:

- `text` now supports TrueType-, PostScript- amd OpenType fonts. For 
now, the syntax remains unchanged, including the `ttf` keyword; the font 
format is detected automagically.

- Fonts installed in the system can be accessed directly by replacing 
`ttf FILENAME` with `sys FONTNAME`, optionally followed by `bold` and/or 
`talic`; e.g. `text { sys "Arial" bold ... }`. (Windows version only for 
now)

- `text` objects now render a bit faster.

Known caveats:

- Glyph positions may be slightly different. This is not a bug but a 
feature, as the old code's glyph positioning algorithm wasn't quite right.

- Needs FreeType 2 on Unix, otherwise `text` primitive will be disabled 
entirely. (Comes bundled with FreeType 2 source code for Windows builds.)

- The `internal NUMBER` mechanism for accessing fonts is currently 
restricted to the `timrom.ttf` font.


Differences to `v3.8.0-x.freetype.3`:

- `text` object performance restored, and even improved. (Turns out the 
previous versions wasted time rendering whitespace, of all things.)

- Based on latest Alpha.


Have fun testing!

Post a reply to this message

Op 7-6-2021 om 16:22 schreef clipka:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 

Thank you indeed.

-- 
Thomas

Post a reply to this message

On 6/7/21 10:22 AM, clipka wrote:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.4
> 
> Differences to the Alpha:
> 
> - `text` now supports TrueType-, PostScript- amd OpenType fonts. For 
> now, the syntax remains unchanged, including the `ttf` keyword; the font 
> format is detected automagically.
> 
> - Fonts installed in the system can be accessed directly by replacing 
> `ttf FILENAME` with `sys FONTNAME`, optionally followed by `bold` and/or 
> `talic`; e.g. `text { sys "Arial" bold ... }`. (Windows version only for 
> now)
> 
> - `text` objects now render a bit faster.
> 
> Known caveats:
> 
> - Glyph positions may be slightly different. This is not a bug but a 
> feature, as the old code's glyph positioning algorithm wasn't quite right.
> 
> - Needs FreeType 2 on Unix, otherwise `text` primitive will be disabled 
> entirely. (Comes bundled with FreeType 2 source code for Windows builds.)
> 
> - The `internal NUMBER` mechanism for accessing fonts is currently 
> restricted to the `timrom.ttf` font.
> 
> 
> Differences to `v3.8.0-x.freetype.3`:
> 
> - `text` object performance restored, and even improved. (Turns out the 
> previous versions wasted time rendering whitespace, of all things.)
> 
> - Based on latest Alpha.
> 
> 
> Have fun testing!

checking whether to use the FreeType library... yes
checking for pkg-config... (cached) pkg-config
checking for FreeType's include path... -I/usr/include/freetype2
checking for library containing FT_Init_FreeType... -lfreetype
checking ft2build.h usability... yes
checking ft2build.h presence... yes
checking for ft2build.h... yes
checking for libfreetype version >= 2.4.0... 2.10.1, ok

that last version check seems odd... i'm at 2.10.1 but it passed, and 
built properly. no testing yet... time for an espresso

Post a reply to this message

Am 08.06.2021 um 20:48 schrieb Ash Holsenback:

> checking for libfreetype version >= 2.4.0... 2.10.1, ok
> 
> that last version check seems odd... i'm at 2.10.1 but it passed, and 

Why, yes, of course.

Remember that the actual version "2.10.1" is _not_ "two one zero one", 
but "two ten one".

Which is greater-or-equal to the required version "2.4.0", which is "two 
four zero".

Post a reply to this message

On 6/8/21 8:33 PM, clipka wrote:
> Am 08.06.2021 um 20:48 schrieb Ash Holsenback:
> 
>> checking for libfreetype version >= 2.4.0... 2.10.1, ok
>>
>> that last version check seems odd... i'm at 2.10.1 but it passed, and 
> 
> Why, yes, of course.
> 
> Remember that the actual version "2.10.1" is _not_ "two one zero one", 
> but "two ten one".
> 
> Which is greater-or-equal to the required version "2.4.0", which is "two 
> four zero".

lol... gotcha. old eye's saw 1 not 10 for some reason. there's a couple 
of ironies there that i won't even get into

Post a reply to this message

On 6/7/21 10:22 AM, clipka wrote:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 

Related too, to the recent developer emails...

I want to say in a public forum - what would help folks like me most is 
an official release of v3.8 more or less exactly (with fixes) as it 
stood when you went on a walk-about years back Christoph!

Why did Tor Olav back out the use of your terrific v3.8 tuple SDL 
enhancement in his vectors.inc documentation? Because, he has to write 
examples to work with v3.7 for 'most' users.

Those of us wanting to make use of the substantial improvements made in 
v3.8 had no choice - after waiting around for a long time - but to treat 
your last v3.8 commit as an effective release. I've now got a mountain 
of stuff written against your last v3.8 commit. This is what it is.

To the degree you and other core developers 'move' the eventual v3.8 
release to be some cool newer, great 'thing,' - you, Chris and whoever 
else deciding - will be screwing those of us long exploiting v3.8 
features, over. I'm now way off in the weeds with source code, scenes 
and include files written mostly against how v3.8 master has now stood 
for YEARS.

If v3.8 gets released more or less as is - especially with respect to 
the parser and vm - it will be something like what v3.7 has been for the 
next 5-10 years. It'll be the stable release 'most' people run. Some of 
my play might still be of use to the POV-Ray community working around 
such a stable v3.8 release.

Plus! I'll be motivated to work on maintenance fixes to the then newer 
v3.8 stable branch as to some degree I'll need to to keep v3.8 compiling 
too. :-)

I'm not now much motivated to play or chase any later and greater 
'official' POV-Ray releases as I was doing for a long time. I'm sorry. 
I'm old. I have ideas with which I want to play - I made the decision to 
to break on v3.8 where it stalled.

Bill P.

Aside: I say all the above actually sort of wanting the freetype 
improvements... It's cool, worthwhile work. I understand too, I'm not a 
typical user.

Post a reply to this message

clipka wrote on 07/06/2021 16:22:
> This is pretty much the same as the alpha just published, but with the 
> new `text` handling.
> 
> 
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.4
> 

Thank you, Clipka!

Paolo

Post a reply to this message

Am 09.06.2021 um 05:17 schrieb William F Pokorny:

> If v3.8 gets released more or less as is - especially with respect to 
> the parser and vm - it will be something like what v3.7 has been for the 
> next 5-10 years. It'll be the stable release 'most' people run. Some of 
> my play might still be of use to the POV-Ray community working around 
> such a stable v3.8 release.

The status quo of the parser is halfway between here and there, so 
especially with respect to the parser, releasing "as-is" won't be an option.

However, see the latest dev newsletter on this issue for the direction 
things are going to head. I guess it's effectively what you are asking for.


> Aside: I say all the above actually sort of wanting the freetype 
> improvements... It's cool, worthwhile work. I understand too, I'm not a 
> typical user.

Just to be clear: Those two recent releases don't bring any new 
features. They just introduce some fixes to the alpha development 
branch, and the experimental FreeType branch, respectively.

Frankly, they're more the result of me checking whether all our tools 
still work as they should than anything else. That, and me wanting to 
make a statement that POV-Ray development has officially been restarted.

Post a reply to this message

I'm curious, but will POV be able to render LaTeX? Or will it still be 
better to convert LaTeX to SVG, and then use Inkscape to generate the 
POV code from the SVG?


Mike

Post a reply to this message

Am 18.06.2021 um 22:43 schrieb Mike Horvath:
> I'm curious, but will POV be able to render LaTeX? Or will it still be 
> better to convert LaTeX to SVG, and then use Inkscape to generate the 
> POV code from the SVG?

What?

I don't really see the connection between support for other font 
formats, and support for a complete (and complex) text document format.

Also, why specifically LaTeX? Why not EPS? RTF? PDF? ODF? DOCX? HTML?

I'll go out on a limb here and predict that POV-Ray will never be able 
to render any of these document formats. Not unless you write a suite of 
macros to do the job.


"Dammit Jim, I'm a 3D renderer, not a typesetting engine!"
   -- POV-Ray

Post a reply to this message