 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Now with support for installed fonts (currently Windows only):
https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.2
Syntax:
TEXT_OBJECT:
text {
sys "Font Name" [FONT_STYLE_MODIFIER...]
Thickness, <Offset>
[OBJECT_MODIFIERS...]
}
FONT_STYLE_MODIFIER:
bold | italic
where "Font Name" is the official name of a font (e.g. "Times New
Roman") installed on the system. By default, the "regular" variant of
the font will be selected; specifying `bold`, `italic` or both will
instead select the bold, italic or bold-italic variant, respectively.
Note that `bold` and `italic` only work as expected if there are actual
dedicated bold/italic font faces installed. POV-Ray will currently /not/
synthesize faux bold or faux italic outlines from the regular font face.
Also, `bold` and `italic` are limited to this new variant of the syntax,
and are /not/ allowed with the classic `ttf` (or `internal`) syntax variant.
At present, the mechanism may produce surprising results if an exact
match for the font name is not found.
As indicated above, the mechanism is currently only fully implemented
for the Windows platform. The syntax /per se/ is accepted on other
platforms as well, but no fonts will be found, leading to a parse error
or, at this point, probably even a crash.
If anyone wants to pick up the glove of implementing the corresponding
functionality for Unix, have a look at `platform/unix/osfontresolver.cpp`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymous org> wrote:
> Now with support for installed fonts (currently Windows only):
> Syntax:
> TEXT_OBJECT:
> text {
> sys "Font Name" [FONT_STYLE_MODIFIER...]
> Thickness, <Offset>
> [OBJECT_MODIFIERS...]
> }
>
> FONT_STYLE_MODIFIER:
> bold | italic
> ...
> As indicated above, the mechanism is currently only fully implemented
> for the Windows platform. The syntax /per se/ is accepted on other
> platforms as well, ...
mildly confused.. does this mean that the syntax will depend on whether the
user chooses a 'sys' or 'ttf' font? is the 'cmap {}' construct only for ttf's,
or has it been junked? in all cases, will scene #version's less than 3.8
continue to work as before?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.01.2019 um 22:10 schrieb jr:
> mildly confused.. does this mean that the syntax will depend on whether the
> user chooses a 'sys' or 'ttf' font?
(Oops, I forgot the "String_of_Text".
But I suspect you didn't even notice, otherwise you should be more than
just "mildly" confused...)
Maybe it's easier to grasp if I present the syntax as follows:
TEXT_OBJECT:
text {
FONT_REFERENCE "Text_of_String"
Thickness, <Offset>
[OBJECT_MODIFIERS...]
}
FONT_REFERENCE:
FILE_FONT_REFERENCE |
INTERNAL_FONT_REFERENCE |
SYSTEM_FONT_REFERENCE
FILE_FONT_REFERENCE:
ttf "font_file.ttf/ttc"
INTERNAL_FONT_REFERENCE:
internal Font_Number
SYSTEM_FONT_REFERENCE:
sys "Font_Name" [bold] [italic]
This new option, SYSTEM_FONT_REFERENCE, is all this particular version
is about and all that I wanted to present in the post.
> is the 'cmap {}' construct only for ttf's,
> or has it been junked? in all cases, will scene #version's less than 3.8
> continue to work as before?
All of these other things require more work in the FreeType version, so
no comment there until I even have a clearer picture myself where I'll
end up with them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2019 um 22:10 schrieb jr:
> > mildly confused.. does this mean that the syntax will depend on whether the
> > user chooses a 'sys' or 'ttf' font?
> (Oops, I forgot the "String_of_Text".
> But I suspect you didn't even notice, otherwise you should be more than
> just "mildly" confused...)
> Maybe it's easier to grasp if I present the syntax as follows:
> TEXT_OBJECT:
> text {
> FONT_REFERENCE "Text_of_String"
> Thickness, <Offset>
> [OBJECT_MODIFIERS...]
> }
>
> FONT_REFERENCE:
> FILE_FONT_REFERENCE |
> INTERNAL_FONT_REFERENCE |
> SYSTEM_FONT_REFERENCE
> FILE_FONT_REFERENCE:
> ttf "font_file.ttf/ttc"
> INTERNAL_FONT_REFERENCE:
> internal Font_Number
> SYSTEM_FONT_REFERENCE:
> sys "Font_Name" [bold] [italic]
> This new option, SYSTEM_FONT_REFERENCE, is all this particular version
> is about and all that I wanted to present in the post.
> > is the 'cmap {}' construct only for ttf's,
> > or has it been junked? in all cases, will scene #version's less than 3.8
> > continue to work as before?
> All of these other things require more work in the FreeType version, so
> no comment there until I even have a clearer picture myself where I'll
> end up with them.
in fewer words, yes, you intend to introduce a syntax where 'FONT_REFERENCE'
(and perhaps more) will depend on the font's source. folly, methinks..
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.01.2019 um 23:32 schrieb jr:
> in fewer words, yes, you intend to introduce a syntax where 'FONT_REFERENCE'
> (and perhaps more) will depend on the font's source. folly, methinks..
And why would you say so?
When specifying a font via file name, you always get a single file,
which typically(*) contains just one single font face; e.g. `arial.ttf`
would give you the Arial Regular font face, while `arialbd.ttf` would
give you the Arial Bold font face. So `text { ttf "arial.ttf" bold ...
}" would make no sense.
When specifying a font via font name, you actually name the font family,
e.g. "Arial", and have to provide additional information to select which
font face of the family you want to load.
(*)As far as /font collections/ are concerned, i.e. files which contain
multiple fonts, I'll still have to do some research to figure out what
that even means and how they work. If it turns out that selectors like
`bold` and/or `italic` are useful for font collections as well, the
syntax for filename-referenced fonts will be extended accordingly. But
not now.
As for /faux bold/ fonts - i.e. bold-looking fonts synthesized "on the
fly" using mathematical transformations, rather than having been
separately constructed by a font designer - if I implement such a
feature I'll probably provide a separate syntax for it, to give the user
full contropl over the magnitude of the effect. Such syntax would be
available independent of the font source, so you could e.g. reference
the bold variant of a system font and synthesize an even bolder font
from it.
As for /faux italic/ (which is actually a misnomer, since such a font
would be an oblique rather than italic font) such an effect can already
be achieved using a shearing transformation on the resulting object.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2019 um 23:32 schrieb jr:
> > in fewer words, yes, you intend to introduce a syntax where 'FONT_REFERENCE'
> > (and perhaps more) will depend on the font's source. folly, methinks..
>
> And why would you say so?
folly ("foolishness")? for one, that is my end-user-perspective reaction to
this course of action. a syntax which depends on the font's source may "get in
the way" for scenes where font selection happens at runtime. it would also add,
unnecessarily IMO, the need having to remember and deal with the variation(s).
and what about (SDL) platform agnosticism? will we wind up with Windows + *NIX
syntaxes?
another reason is the "declared so" status, ie
> TEXT_OBJECT:
> text {
> FONT_REFERENCE "Text_of_String"
> Thickness, <Offset>
> [OBJECT_MODIFIERS...]
> }
> FONT_REFERENCE:
> FILE_FONT_REFERENCE |
> INTERNAL_FONT_REFERENCE |
> SYSTEM_FONT_REFERENCE
> FILE_FONT_REFERENCE:
> ttf "font_file.ttf/ttc"
> INTERNAL_FONT_REFERENCE:
> internal Font_Number
> SYSTEM_FONT_REFERENCE:
> sys "Font_Name" [bold] [italic]
> This new option, SYSTEM_FONT_REFERENCE, is all this particular version
> is about and all that I wanted to present in the post.
so SYSTEM_FONT_REFERENCE has been "set in stone" already while the other two
types remain .. in flux.
but, since the 'text' is being reworked anyway, why do only half the job? I'd
have thought that the <Offset>, for instance, should be be part of
FONT_REFERENCE as it's about kerning. and Thickness, in a sense, is redundant;
a glyph's x + y extents are already provided, and subsequent scaling will be
needed in almost all cases anyway.
my impression of the whole thing is very much .. not thought through.
have you considered using a dictionary? one common-to-all key telling
sys|int|ttf, and the remaining keys dependent, perhaps[*]? the 'text' primitive
could then be as simple as:
text {
dictionary
"Text_of_String"
[OBJECT_MODIFIERS...]
}
[*] ideally each type ignores not-applicable keys.
regards, jr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Now with support for installed fonts (currently Windows only):
>
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-x.freetype.2
>
> Syntax:
>
> TEXT_OBJECT:
> text {
> sys "Font Name" [FONT_STYLE_MODIFIER...]
> Thickness, <Offset>
> [OBJECT_MODIFIERS...]
> }
>
> FONT_STYLE_MODIFIER:
> bold | italic
I really like this!!! And at long last something that makes the painful process
to move POV-Ray to AGPL look like it was worth it!
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.01.2019 um 12:04 schrieb jr:
> and what about (SDL) platform agnosticism? will we wind up with Windows + *NIX
> syntaxes?
That may be the case; we shall see. Remember that the whole concept of
using fonts installed on the system is inherently leaving the terrain of
platform agnosticism anyway, since a font installed on one system may be
absent (or named differently) on another. You're inevitably leaving the
territory of where you can pack up a scene and its accompanying files,
carry it to another computer, unpack it there and expect it to render.
And if operating system FnordOS has no font names, and instead looks up
installed fonts via attributes such as "serif", "monospaced" etc., then
we have to get back to the drawing board and think up a useful but
ultimately dedicated syntax for that particular platform.
> another reason is the "declared so" status, ie
>
>> TEXT_OBJECT:
>> text {
>> FONT_REFERENCE "Text_of_String"
>> Thickness, <Offset>
>> [OBJECT_MODIFIERS...]
>> }
>
>> FONT_REFERENCE:
>> FILE_FONT_REFERENCE |
>> INTERNAL_FONT_REFERENCE |
>> SYSTEM_FONT_REFERENCE
>> FILE_FONT_REFERENCE:
>> ttf "font_file.ttf/ttc"
>> INTERNAL_FONT_REFERENCE:
>> internal Font_Number
>> SYSTEM_FONT_REFERENCE:
>> sys "Font_Name" [bold] [italic]
>> This new option, SYSTEM_FONT_REFERENCE, is all this particular version
>> is about and all that I wanted to present in the post.
>
> so SYSTEM_FONT_REFERENCE has been "set in stone" already while the other two
> types remain .. in flux.
In what sense would the other two remain in flux that wouldn't apply to
SYSTEM_FONT_REFERENCE also?
(And no, I won't let font collection related changes count. It's
probably more fitting to think of those as yet a fourth alternative to
the above, which hasn't been added yet.)
The `cmap` stuff will apply to all of the above, if that's what you're
talking about. As would be a "faux bold" parameter: Even if the font
face is already bold by original design, a user might want to make it
even bolder.
> but, since the 'text' is being reworked anyway, why do only half the job?
The /implementation/ is being reworked, but the /syntax/ is being
retained and just extended. That's why.
> I'd have thought that the <Offset>, for instance, should be be part of
> FONT_REFERENCE as it's about kerning. and Thickness, in a sense, is redundant;
> a glyph's x + y extents are already provided, and subsequent scaling will be
> needed in almost all cases anyway.
FONT_REFERENCE is /exclusively/ about what "original design" to pick and
start from. `<Offset>`, in contrast, is about how to /modify/ that
original design, being an /addition/ to whatever advance width (and
kerning, if applicable) the original font designer had envisioned.
Thickness could indeed be emulated by scaling, but it's there, so for
the sake of backward compatibility we can't simply throw it away.
> have you considered using a dictionary? one common-to-all key telling
> sys|int|ttf, and the remaining keys dependent, perhaps[*]? the 'text' primitive
> could then be as simple as:
> text {
> dictionary
> "Text_of_String"
> [OBJECT_MODIFIERS...]
> }
"One parameter to rule them all" - no, not a fan. We're not doing that
for any other object either, so why should we for `text`?
That would, as a last consequence, lead to abominations like the following:
#declare parameters = dictionary;
parameters.center = <0,0,0>;
parameters.radius = 1;
parameters.texture = ...
...
sphere { parameters }
Is that what you want? I highly doubt it.
We can discuss a syntax like this:
#declare MyFont1 = font { sys "Times New Roman" italic }
#declare MyFont2 = font { ttf "arialbd.ttf" }
text { MyFont "Hello World" ... }
especially since it would come in handy for some other font-related
features I envision for the future, such as accessing font metrics. But
at the moment implementing such a thing would exceed my time and energy
budget for font stuff, since introducing new variable types to the
parser is (as yet) a high-level magic spell that drains a lot of mana.
For the time being, extending the existing syntax is the motto of the
day. And since we need /some/ mechanism to tell POV-Ray whether to use
the Regular or Bold face when specifying a font by family name, it is
necessary to add /some/ parameter that is meaningless at best or
confusing at worst when specifying a font by file name, and should
therefore not be accepted in such a context.
And finally, if you need a "one parameter to rule them all" syntax,
there's always the possibility to write a corresponding macro.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
thank you for the detailed/informative reply.
clipka <ano### [at] anonymousorg> wrote:
> > and what about (SDL) platform agnosticism? ...
>
> That may be the case; ... You're inevitably leaving the
> territory of where you can pack up a scene and its accompanying files,
> carry it to another computer, unpack it there and expect it to render.
unfortunate but true.
one (Tcl's) approach is to have platform and architecture stuff in a single
(associative) array.
> The `cmap` stuff will apply to all of the above, if that's what you're
> talking about.
that was part of my concerns.
> "One parameter to rule them all" - no, not a fan. We're not doing that
> for any other object either, so why should we for `text`?
>
> That would, as a last consequence, lead to abominations like the following:
> ...
> sphere { parameters }
> Is that what you want? I highly doubt it.
> ...
> We can discuss a syntax like this:
> #declare MyFont1 = font { sys "Times New Roman" italic }
> #declare MyFont2 = font { ttf "arialbd.ttf" }
> text { MyFont "Hello World" ... }
>
> especially since it would come in handy for some other font-related
> features I envision for the future, such as accessing font metrics.
personally, I'd like that. (particularly if it were a {key value} style list.
:-))
and yes regarding the import/value of remaining consistent (across objects).
> And finally, if you need a "one parameter to rule them all" syntax,
> there's always the possibility to write a corresponding macro.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
