It is currently November 26th, 2022, 8:01 pm

Fonts

Report bugs with the Rainmeter application and suggest features.
MattKing
Developer
Posts: 98
Joined: August 6th, 2009, 3:03 pm

Re: Fonts

Post by MattKing »

jsmorley wrote:Works like a champ so far!!!

[Rainmeter]
Author=Jeffrey Morley
Update=1000
LocalFont=#PROGRAMPATH#Fonts\TheSaBdCp.TTF

[Variables]
FontColor=255,255,255,255
FontFace=TheSansBold-Caps
FontSize=11
StringEffect=NONE

I removed that font from \Windows\Fonts and put it in C:\Program Files\Rainmeter\Fonts and the skin comes right up with the correct font smooth as silk.

Now going to reboot to be sure there was not some vestige of the installed font left in memory.

Edit: Yep, comes up with the right font without even a second of hesitation. Now I will load and unload the skin a few dozen times to be sure it isn't "building up" any memory usage.

Edit: Seems fine. Rainmeter ALWAYS had a small (about 150 bytes per time) memory creep when you load and unload skins or do a "refresh all" of Rainmeter. I tested it (first using your code then the original .exe/.dll) with about a dozen close skin / open skin then about a dozen refresh all while watching the memory with Process Explorer and am still getting the same 150 +- bytes creep with either the old .exe/.dll or the new ones. So it passes that test.
Awesome awesome.

I have another idea that could be sort of useful.

Font Styles for MeterString meters. I find it very annoying to have to put in #fontHeight#, #fontName# stuff every time I create a new MeterString meter. So I think we should make a section for font styles like:

Code: Select all

[FontStyle1]
FontFace="Some font"
FontColor=0,0,0,255
FontEffectColor=255,255,255,255
Prefix=""
Postfix=""
FontSize=10
StringAlign= LEFT
StringStyle=NORMAL
StringEffect=SHADOW
And then in the MeterString

Code: Select all

[SomeStringMeter]
Meter=String
FontStyle=FontStyle1
X=20
Y=20
W=100
H=200
Text="This Meter uses font styles by Matt King! Yeah!"
We would need some way to indicate that a font style section was actually a font style section.

I think this could be useful to some people, and it shouldn't be too difficult to implement. I could even do it yay.
User avatar
Kaelri
Developer
Posts: 1721
Joined: July 25th, 2009, 4:47 am

Re: Fonts

Post by Kaelri »

I love this idea, especially in tandem with gschoppe's common .INI concept. Why don't we generalize it?

Code: Select all

[StyleA]
Style=1
Key1=Value1
Key2=Value2
Key3=Value3

[StyleB]
Style=1
Key4=Value4
Key5=Value5
Key6=Value6

[MeterC]
Meter=STRING
StyleName=StyleA
StyleName2=StyleB
Key1=OverrideValue1
"Style=1" would indicate that the section was a style definition, not a meter or measure. The rest of the keys could be anything - font properties, update dividers, etc. Once defined, any measure or meter could refer to any number of these styles, all of whose keys (excluding Style=1) would be taken to apply.

To be safe, we may still want to require all measures to have their own Measure=, and likewise with meters and Meter=. The other question is what to do with dynamic variables: would they have to be enabled for the style? The measure/meter? Both?

The other request I'd have for a mechanism like this is that if a key is defined both in the style and in the meter, the latter takes priority. That way, if we want to have a meter that shares all the properties of the style except for one thing - like color, or size - we don't have to set all the individual keys.

At any rate, I'm a fan of the concept in whatever form. :)
MattKing
Developer
Posts: 98
Joined: August 6th, 2009, 3:03 pm

Re: Fonts

Post by MattKing »

Kaelri wrote:I love this idea, especially in tandem with gschoppe's common .INI concept. Why don't we generalize it?

Code: Select all

[StyleA]
Style=1
Key1=Value1
Key2=Value2
Key3=Value3

[StyleB]
Style=1
Key4=Value4
Key5=Value5
Key6=Value6

[MeterC]
Meter=STRING
StyleName=StyleA
StyleName2=StyleB
Key1=OverrideValue1
"Style=1" would indicate that the section was a style definition, not a meter or measure. The rest of the keys could be anything - font properties, update dividers, etc. Once defined, any measure or meter could refer to any number of these styles, all of whose keys (excluding Style=1) would be taken to apply.

To be safe, we may still want to require all measures to have their own Measure=, and likewise with meters and Meter=. The other question is what to do with dynamic variables: would they have to be enabled for the style? The measure/meter? Both?

The other request I'd have for a mechanism like this is that if a key is defined both in the style and in the meter, the latter takes priority. That way, if we want to have a meter that shares all the properties of the style except for one thing - like color, or size - we don't have to set all the individual keys.

At any rate, I'm a fan of the concept in whatever form. :)
Would have to rewrite every measure and meter to have it be general. if I have time I would do that. I like the idea for Strings the best, as it is the most likely thing to reuse a whole bunch of variables.