this was caused by a problem related to bug 336 and does actually work
correctly.

The paths to fonts is definately not an absolute paths, found in the sample
applications.

for example;
Button Shared Resource tag: 
  <labelfont value="fonts/Vera.ttf"/>

The path is actually point to here:
\ms4w\apps\chameleon\htdocs\skins\default\fonts\

Where the html sample templates are here:
\ms4w\apps\chameleon\sample\htdocs\

Paul this seems kind off over complicated, is this true?

Chris, I believe this is the new "skinable" way of declaring a font path.  The
"fonts" keyword actually gets replaced on the fly by the current skin directory.

Paul can confirm if this is true or not.

I need a methodology to test that this bug is fixed.

I modified a font path in a sharedresource of a sample application and the font
was found.

it should support absolute paths (thus ignoring skins) and relative paths as per
skinning logic.  Per skinning logic, every registered skin will be searched in
order from the last one registered to the first one registered, then the default
skin provided with chameleon.

To test, you can try with both absolute path and relative paths in a template,
with caching turned off in the textbutton shared resource to make sure that it
works properly I guess.

Absolute path is working well.

Default skins is found as well.

But when I move the skins/default/fonts to skins/sample directory and remove the
"$oApp->registerSkin( 'skins/sample' );" line in the sample application
(.phtml), font are found anyway.

Also when I move the skins/default/fonts to skins/sample2 directory (I created
this directory) and add "$oApp->registerSkin( 'skins/sample2' );" line, font is
not found.

I used the "sample_enhanced.phtml".

Norm should this bug be reopened? or are you waiting for paul to check it out
first?

Chris you are right.  We should reopen this bug.

Changed target to 1.99 Beta 3.

a note on this.  The font may be found in the case of invalid skins because the
buttonizer will attempt one last desperate guess at a font that should always be
included ... I should review this to see if I should actually include this font
with the buttonizer or if I could possibly use one of the built-in fixed-size
fonts for this purpose ... the idea being that if anything goes wrong we can
work around it.

The issue of the font not being found in a skin directory will have to be
researched ... tomorrow :)

added Vera.ttf to buttonizer to be used in case requested font not found.  An
error message will still be emitted to the ErrorManager if installed/used in the
associated chameleon template.

I verified that the label font is located using the same process as all other
button elements.  I then checked to see the progression of fallback from local
skins, default skin, and finally buttonizer default and it seems to work fine.

I think the confusion here is that the buttonizer does try to make some guesses
along the way and if you have the font anywhere it might look it will find it.

If testing this again, use a font other than Vera.ttf to test since buttonizer
will now use Vera.ttf as a last resort.

Change font sharedresource paths to a different fonttype in a different
directory and defined an adsolute path to it for the three different shared
resources for:
http://localhost/chameleon/samples/sample_enhanced.phtml

The font is changed for every button using these shared resources except for the
TAB shared resource on the Link Widget Tabs.

I cheaked to see if the Styleresource is even being registered for the Link
widgets and I was able to change the Tab height, but not the font type.

If this is a separate bug let me know so that we can close this one. :)

Chris, please attach your template to this bug.

Created an attachment (id=53) [details]
absolute path to font sharedresource parameter

Paul here is the template I was working on with my changes.

invalid, this works.  A couple of comments:

1. the tabs don't use the font, the labels are actually part of the graphic on
the tabs.

2. the font path is really:

D:\ms4w\apps\chameleon\htdocs\skins\default\fonts\VeraSeBd.ttf

instead of

D:\ms4w\apps\chameleon\htdocs\skins\default\VeraSeBd.ttf

3. the error reporting sucks because the return value is false, and this is used
as the font file, so when the error is reported there is no path listed (and
there should be).  I've fixed this ... you can now change to an invalid font and
it will give you a better warning ...

As a side note, I cleaned up chameleon's findFile function:

* added test for absolute paths before beginning searches
* added clearstatcache() before file_exists() as per php documentation

these changes are not required to get this to work.

ha, confirmed that the tab are whole graphics. 

setting the bug to verified. 

Verified on Fedora Core 2.  Nice works.  Question:  Is it possible to add the
name of the font not found in the error message?  It may help debugging template
where you could have a large number of fonts.

see comment #16: 

"3. the error reporting sucks because the return value is false, and this is used
as the font file, so when the error is reported there is no path listed (and
there should be).  I've fixed this ... you can now change to an invalid font and
it will give you a better warning ..."

The error report should now read something like:

"ERROR: Button.php was unable to find the font 'fonts/VeraBlah.ttf' in any of
the registered or default skins."

I read comment #16 before but didn't check dates.  Heech!

verified on windows beta 3 20041101

setting to closed

I checked comment #19 and it works on Fedora Core 2.