Firefox 3.0pre and fonts
Christian Hennecke
I downloaded the Firefox 3.0pre. Unfortunately, all of the GUI is
displayed in a serif font instead of the usual WarpSans. I installed the
latest version of Alex Taylor's Workplace Sans but that doesn't have any
effect. Do I need to adapt any configuration files?
--
"I smell blood and an era of prominent madmen." - W.H. Auden
Steve Wendt
> I downloaded the Firefox 3.0pre. Unfortunately, all of the GUI is
> displayed in a serif font instead of the usual WarpSans. I installed the
> latest version of Alex Taylor's Workplace Sans but that doesn't have any
> effect. Do I need to adapt any configuration files?
You might need to reset the font cache in the INI files.
William L. Hartzell
And how does one do this? And which font cache entry do you speak?
--
Bill
Thanks a Million!
Felix Miata
> I downloaded the Firefox 3.0pre. Unfortunately, all of the GUI is
> displayed in a serif font instead of the usual WarpSans. I installed the
> latest version of Alex Taylor's Workplace Sans but that doesn't have any
> effect. Do I need to adapt any configuration files?
If you fail to find the actual cause and solution, you can work around the
problem using the file chrome\userChrome.css in your profile directory. If it
doesn't exist, create it in a text editor, and add the following line:
* {font-family: sans-serif}
--
"Where were you when I laid the earth's
foudation?" Matthew 7:12 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
Steve Wendt
>> You might need to reset the font cache in the INI files.
> And how does one do this? And which font cache entry do you speak?
1) Close all Mozilla 1.9.x products
2) Start RegEdit2 (or some other INI editor)
3) In HINI_USER_PROFILE, find the PM_Fonts_FontConfig_Cache_v1.1 key and
delete it
4) Start your browser again
I opened bug 439187 for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=439187
Christian Hennecke
wrote:
Does not help. The entry is recreated without information about wpsu.ttf
again. If I use userChrome.css and set
* { font-family: "Workplace Sans"; }
I do get a sans-serif font, but it sure as hell is NOT Workplace Sans.
Steve Wendt
> The entry is recreated without information about wpsu.ttf
I had a lot of trouble with wpsu.ttf immediately after installing it,
and rebooting seemed to clear it up (in case you have not done that
yet). The problems were with OpenOffice 2.0.x, but I'm not sure that is
relevant.
Peter Weilbacher
> * { font-family: "Workplace Sans"; }
>
> I do get a sans-serif font, but it sure as hell is NOT Workplace Sans.
You could use the program contained in
http://temp.weilbacher.org/fonts_test.zip
to see what fonts Mozilla apps will see. If you don't see any problems
yourself, you could post the list it outputs here or as an attachment to
https://bugzilla.mozilla.org/show_bug.cgi?id=432575
--
Please | Official Warpzilla Ports: http://www.mozilla.org/ports/os2/
reply in |
newsgroup | Enhanced OS/2 builds: http://pmw-warpzilla.sf.net/
Steve's Warpzilla Tips: http://www.os2bbs.com/os2news/Warpzilla.html
Christian Hennecke
<news...@weilbacher.org> wrote:
> On 14.06.08 11:34, Christian Hennecke wrote:
> > * { font-family: "Workplace Sans"; }
> >
> > I do get a sans-serif font, but it sure as hell is NOT Workplace Sans.
>
> You could use the program contained in
> http://temp.weilbacher.org/fonts_test.zip
> to see what fonts Mozilla apps will see. If you don't see any problems
> yourself, you could post the list it outputs here or as an attachment to
> https://bugzilla.mozilla.org/show_bug.cgi?id=432575
Well, I managed so work around the problem. I had quite a few fonts
installed. After de-installing and re-installing them, Minefield now
starts up using wpsu.ttf. I've seen this problem with one other
application, TrueSpectra Photo>Graphics. Could it be that the font
component doesn't allocate enough memory to handle larger amounts of
fonts?
The GUI fonts are pretty small. I'm using the Innotek font library 2.6.
Is there any way to make this larger?
Heiko Nitzsche
>> And how does one do this? And which font cache entry do you speak?
>
> 1) Close all Mozilla 1.9.x products
> 2) Start RegEdit2 (or some other INI editor)
> 3) In HINI_USER_PROFILE, find the PM_Fonts_FontConfig_Cache_v1.1 key and
> delete it
> 4) Start your browser again
Is it really necessary to put the cache into the global user config file?
Based on the recommendation I checked my ini file and found that there
were already 5 of these caches created obviously by different lib versions.
After removing all of them my ini file shrinked by more than a 1 MB (by 25% !!!)
as I have quite some fonts installed. As we all know that there are problems
with available shared memory, storing such big amount of data should be
rethought. Also WPS seems to not really like big INI files.
Wouldn't it be sufficient to store a path to a separated INI file where
the cached data is stored (e.g. OS2/FNTCACHE.INI) ?
Peter Weilbacher
> Well, I managed so work around the problem. I had quite a few fonts
> installed. After de-installing and re-installing them, Minefield now
> starts up using wpsu.ttf. I've seen this problem with one other
> application, TrueSpectra Photo>Graphics. Could it be that the font
> component doesn't allocate enough memory to handle larger amounts of
> fonts?
What is a "larger amount of fonts"? I had about 150 fonts installed at
some point, and it worked.
> The GUI fonts are pretty small. I'm using the Innotek font library 2.6.
> Is there any way to make this larger?
The Innotek library doesn't apply any more. This could be
https://bugzilla.mozilla.org/show_bug.cgi?id=439195
which is either a weirdness in PM, in WarpSans or Workplace Sans, or
somewhere else. I tend to think that I shouldn't fix it because any fix
would be awfully hacky and might break other configurations.
Peter Weilbacher
> Is it really necessary to put the cache into the global user config file?
>
> Based on the recommendation I checked my ini file and found that there
> were already 5 of these caches created obviously by different lib versions.
>
> After removing all of them my ini file shrinked by more than a 1 MB (by
> 25% !!!)
> as I have quite some fonts installed. As we all know that there are
> problems
> with available shared memory, storing such big amount of data should be
> rethought. Also WPS seems to not really like big INI files.
>
> Wouldn't it be sufficient to store a path to a separated INI file where
> the cached data is stored (e.g. OS2/FNTCACHE.INI) ?
I don't think this would work correctly on setups with multiple
desktops on the same machine. But please ask Doodle.
It's great that you all find so many problems and are posting them, but
why didn't you post them half a year ago when there was still time to
solve them?
Christian Hennecke
<news...@weilbacher.org> wrote:
> > Well, I managed so work around the problem. I had quite a few fonts
> > installed. After de-installing and re-installing them, Minefield now
> > starts up using wpsu.ttf. I've seen this problem with one other
> > application, TrueSpectra Photo>Graphics. Could it be that the font
> > component doesn't allocate enough memory to handle larger amounts of
> > fonts?
>
> What is a "larger amount of fonts"? I had about 150 fonts installed at
> some point, and it worked.
There are 345 fonts installed, including variants for italic and bold.
> > The GUI fonts are pretty small. I'm using the Innotek font library 2.6.
> > Is there any way to make this larger?
>
> The Innotek library doesn't apply any more. This could be
> https://bugzilla.mozilla.org/show_bug.cgi?id=439195
> which is either a weirdness in PM, in WarpSans or Workplace Sans, or
> somewhere else. I tend to think that I shouldn't fix it because any fix
> would be awfully hacky and might break other configurations.
That exactly describes my problem. I have the SDDFONTDPI=96 setting at a
resolution of 1600x1200. To get the correct size for the GUI elements, I
have to use:
* { font-size: 11pt !important; }
Looks like the problem gets worse at higher resolutions.
BTW, what was the reason to stop using the same font that the system
uses for menus? IMO that was a bad decision and makes Firefox a
"non-well-behaved app."
Christian Hennecke
<news...@weilbacher.org> wrote:
> It's great that you all find so many problems and are posting them, but
> why didn't you post them half a year ago when there was still time to
> solve them?
Well, I can only speak for myself but basically I have to avoid running
alpha or beta quality software. That's also why I'm still using eCS 1.2R
instead of a 2.0 release candidate. There are two reasons: First, I
simply don't have the time to give things a good test-drive or deal with
larger problems. Second, I use this machine for my daily work, and I
cannot afford having it unavailable because some application goes
berzerk and hoses up the system.
Felix Miata
> On Sun, 15 Jun 2008 14:34:50 UTC, Peter Weilbacher
>> https://bugzilla.mozilla.org/show_bug.cgi?id=439195
> That exactly describes my problem. I have the SDDFONTDPI=96 setting at a
> resolution of 1600x1200. To get the correct size for the GUI elements, I
> have to use:
> * { font-size: 11pt !important; }
> Looks like the problem gets worse at higher resolutions.
Maybe we could come up with suggestions if we could see your problem in
context. Can you upload a screenshot of your whole desktop including several
apps, plus the upper portion of
http://fm.no-ip.com/auth/Font/fonts-face-systypes.html or
http://fm.no-ip.com/auth/dpi-screen-window.html loaded in Firefox 3? You can
see mine in the attachments to bug 439195. IMO, no one running OS2/eCS at
more than 1024X768 should be attempting to apply 96 DPI settings if they want
the best looking fonts possible, if at all. The OS/2 desktop and system fonts
were designed way way back when 1024x768 was "high resolution", which it
wasn't, and isn't. Using 120 DPI settings helps some to get around that
ancient legacy.
Heiko Nitzsche
>> the cached data is stored (e.g. OS2/FNTCACHE.INI) ?
>
> I don't think this would work correctly on setups with multiple
> desktops on the same machine. But please ask Doodle.
To differentiate profiles for Firefox and SeaMonkey it would be a
possibility to store the profiles in their user profile directory.
This way multiple users may have different settings.
But why? The cache content seems to be only font related. AFAIK fonts
cannot be shared across different desktops because they are usually
stored in a fixed directory anyway (not per desktop).
> It's great that you all find so many problems and are posting them, but
> why didn't you post them half a year ago when there was still time to
> solve them?
Sorry, but I usually don't check my user profile content ;) because
I thought that the usage rules are known. The perfect scenario would
still be that every application has its own profile in its directory.
Otherwise we end up with the same mess like on Windows and its registry.
Just because of Steve's hint I had a look.
Also there were so many discussions about shared memory problems
(I think user and system profile data is in shared memory).
Christian Hennecke
<UgaddaBkidd...@dev.nul> wrote:
> > That exactly describes my problem. I have the SDDFONTDPI=96 setting at a
> > resolution of 1600x1200. To get the correct size for the GUI elements, I
> > have to use:
>
> > * { font-size: 11pt !important; }
>
> > Looks like the problem gets worse at higher resolutions.
>
> Maybe we could come up with suggestions if we could see your problem in
> context. Can you upload a screenshot of your whole desktop including several
> apps, plus the upper portion of
> http://fm.no-ip.com/auth/Font/fonts-face-systypes.html or
> http://fm.no-ip.com/auth/dpi-screen-window.html loaded in Firefox 3?
Done.
> IMO, no one running OS2/eCS at
> more than 1024X768 should be attempting to apply 96 DPI settings if they want
> the best looking fonts possible, if at all. The OS/2 desktop and system fonts
> were designed way way back when 1024x768 was "high resolution", which it
> wasn't, and isn't. Using 120 DPI settings helps some to get around that
> ancient legacy.
To be frank: No way. I didn't buy a monitor that can do 1600x1200 to
sacrifice the gain in screen real estate to larger fonts and huge dialog
boxes.
Dave Yeo
[...]
>
> BTW, what was the reason to stop using the same font that the system
> uses for menus? IMO that was a bad decision and makes Firefox a
> "non-well-behaved app."
The problem is that freetype does not support bitmapped fonts. Peter
does not have time to add the code to freetype so we are left with using
fonts that freetype supports.
Personally I'm just happy to have up to date browsers that fit in as
well as they do on the OS/2 desktop and Peter has done a great job in
maintaining the Mozilla codebase.
Dave
Felix Miata
>> IMO, no one running OS2/eCS at
>> more than 1024X768 should be attempting to apply 96 DPI settings if they want
>> the best looking fonts possible, if at all. The OS/2 desktop and system fonts
>> were designed way way back when 1024x768 was "high resolution", which it
>> wasn't, and isn't. Using 120 DPI settings helps some to get around that
>> ancient legacy.
> To be frank: No way. I didn't buy a monitor that can do 1600x1200 to
> sacrifice the gain in screen real estate to larger fonts and huge dialog
> boxes.
That's perfectly fine and understandable. There are two classes of people who
buy bigger displays:
1-those, like you, who want to fit more things on the desktop
2-those, like me, who want things to be big enough to see
Regardless, it's obvious in your screenshot which you are, just as it's
obvious that FF3 on your desktop is using smaller menu text than everything else.
I thought that Peter had changed 1.9 in a way that prevented use of system
fonts, in this case, WarpSans.9, which I see in all your other apps. At least
as to text in the viewport, WarpSans is not displayed when called by a web
page with FF3. I'm not so sure about that in the FF3 UI however. What it
looks to me like is that FF3 is somehow getting the officially "non-existent"
WarpSans.7 bold, at least in size, maybe an artificially bolded Workplace
Sans in 7pt.
Several years ago Mike Kaply explained to me that offically, WarpSans.9 is
the "only" WarpSans, but that in actuality there are two WarpSans sizes. The
smaller is selected as WarpSans.9 by the system on systems running 640x480 or
800x600, and the larger is selected as WarpSans.9 on systems running every
resolution higher than 800x600.
The Geckos have for as far back as he explained this to me been able to
provide the other size regardless that the system pretends it doesn't exist.
So, if you run "120 DPI" (resolution above 800x600), you get the larger
WarpSans if 9pt or larger is called, and the smaller WarpSans if less than
9pt is called (or maybe if less than 8pt is called). Conversely, if you run
"96 DPI" (800x600 or less), you get the larger if >9pt is called, and the
smaller if 9pt or less is called.
IIRC, setting SDDFONTSIZE mucks this up, but take another look at my URL in
your screenshot just above its horizontal rule to see the WarpSans behavior
in FF2 or SM 1.1.9 to see what I mean. Then have another look after changing
SDDFONTSIZE=small to SDDFONTSIZE=medium and rebooting.
Steve Wendt
> There are 345 fonts installed, including variants for italic and bold.
Wow, that is a lot.
> BTW, what was the reason to stop using the same font that the system
> uses for menus? IMO that was a bad decision and makes Firefox a
> "non-well-behaved app."
It wasn't a decision to change it, as much as a lack of support in
FreeType for non-standard fonts:
https://bugzilla.mozilla.org/show_bug.cgi?id=439190
Christian Hennecke
wrote:
> > There are 345 fonts installed, including variants for italic and bold.
>
> Wow, that is a lot.
Well, if you don't count the ones that are installed by Star Office and
Lotus Smartsuite, the number decreases quite a bit.
> > BTW, what was the reason to stop using the same font that the system
> > uses for menus? IMO that was a bad decision and makes Firefox a
> > "non-well-behaved app."
>
> It wasn't a decision to change it, as much as a lack of support in
> FreeType for non-standard fonts:
> https://bugzilla.mozilla.org/show_bug.cgi?id=439190
Thanks for the pointer.
Peter Weilbacher
>>> Wouldn't it be sufficient to store a path to a separated INI file where
>>> the cached data is stored (e.g. OS2/FNTCACHE.INI) ?
>>
>> I don't think this would work correctly on setups with multiple
>> desktops on the same machine. But please ask Doodle.
>
> To differentiate profiles for Firefox and SeaMonkey it would be a
> possibility to store the profiles in their user profile directory.
> This way multiple users may have different settings.
This is not a FF/SM setting, it is a FontConfig thing! It's used by
other cairo apps, too.
> But why? The cache content seems to be only font related. AFAIK fonts
> cannot be shared across different desktops because they are usually
> stored in a fixed directory anyway (not per desktop).
Exactly, the installed fonts can be different depending on the desktop
running. So the most logical way to store the font cache is to use the
same location that PM uses to store its font settings, in the USER_INI
file.
>> It's great that you all find so many problems and are posting them, but
>> why didn't you post them half a year ago when there was still time to
>> solve them?
>
> Sorry, but I usually don't check my user profile content ;) because
> I thought that the usage rules are known. The perfect scenario would
> still be that every application has its own profile in its directory.
> Otherwise we end up with the same mess like on Windows and its registry.
> Just because of Steve's hint I had a look.
>
> Also there were so many discussions about shared memory problems
> (I think user and system profile data is in shared memory).
As you might remember, we first used the standard FontConfig on OS/2
which uses XML-files (%HOME%\.fonts.conf) to store the font settings.
We changed that to use the INI files, partly because users complained
that XML file creation was too slow.
Going to another INI file won't help anyway, as you can see in the
threads about WarpIn corruptions in coo.apps. The only way would be
another file format that again would likely have drawbacks regarding
performance. Not to mention the work needed to rework it. I certainly
won't do that!
Peter Weilbacher
> Going to another INI file won't help anyway, as you can see in the
> threads about WarpIn corruptions in coo.apps. The only way would be
> another file format that again would likely have drawbacks regarding
> performance. Not to mention the work needed to rework it.
Actually, Doodle thought that the shared memory problem would not (or
less) affect other INI files. And he was really quick rewriting our
FontConfig. It now reads and writes from/to %HOME%\fccache.ini (or
%TEMP%\fccache.ini or .\fccache.ini).
I think his rewrite didn't cause any new problems so I will use it in FF
3.0, which I have held up for this for a few hours, and subsequent
nightlies.
Steve Wendt
> Actually, Doodle thought that the shared memory problem would not (or
> less) affect other INI files. And he was really quick rewriting our
> FontConfig. It now reads and writes from/to %HOME%\fccache.ini (or
> %TEMP%\fccache.ini or .\fccache.ini).
>
> I think his rewrite didn't cause any new problems so I will use it in FF
> 3.0, which I have held up for this for a few hours, and subsequent
> nightlies.
Uh oh, a last minute change... ;-/
William L. Hartzell
I've just compiled SeaMonkey trunk using the new fontconfig file and
used it to visit a few web sites. No problems here. I like this better
as it moves a possible bug source (memory using addition) from OS2's ini
files.
Christian Hennecke
<news...@weilbacher.org> wrote:
> > Going to another INI file won't help anyway, as you can see in the
> > threads about WarpIn corruptions in coo.apps. The only way would be
> > another file format that again would likely have drawbacks regarding
> > performance. Not to mention the work needed to rework it.
>
> Actually, Doodle thought that the shared memory problem would not (or
> less) affect other INI files. And he was really quick rewriting our
> FontConfig. It now reads and writes from/to %HOME%\fccache.ini (or
> %TEMP%\fccache.ini or .\fccache.ini).
>
> I think his rewrite didn't cause any new problems so I will use it in FF
> 3.0, which I have held up for this for a few hours, and subsequent
> nightlies.
No problems here. Great job, Peter and Doodle!
Actually, some things *did* change with 3.0 GA. Just to make sure I did
the following:
- De-install Innotek FT2LIB, remove any entries in INI files, re-install
2.60
- Remove PM_Fonts_Fontcache* entries from INI file
- Install Firefox 3.0
With SDDFONTDPI=96 and SDDFONTSIZE=small, the fonts are still too small,
but I can work-around the problem by:
- Setting layout.css.dpi to 120. This corrects the font sizes used to
display web sites, but not for the GUI.
- Add the following statement to userChrome.css
* { font-size: 9pt !important; }
This corrects the font size used to display the GUI.
Steve Wendt
> With SDDFONTDPI=96 and SDDFONTSIZE=small, the fonts are still too small,
For anyone else reading, this is bug 439195:
https://bugzilla.mozilla.org/show_bug.cgi?id=439195
> - Setting layout.css.dpi to 120. This corrects the font sizes used to
> display web sites, but not for the GUI.
Hmm... the fonts used for web sites didn't look too small in my case.
> - Add the following statement to userChrome.css
> * { font-size: 9pt !important; }
Previously, you said you needed 11pt (and 9pt should be the default) -
what's different now?
Christian Hennecke
wrote:
I still do if layout.css.dpi is set to -1 or 96.
Heiko Nitzsche
> less) affect other INI files. And he was really quick rewriting our
> FontConfig. It now reads and writes from/to %HOME%\fccache.ini (or
> %TEMP%\fccache.ini or .\fccache.ini).
>
> I think his rewrite didn't cause any new problems so I will use it in FF
> 3.0, which I have held up for this for a few hours, and subsequent
> nightlies.
Wow, what a quick response! I asked Doodle just one day ago.
Excellent!!!
After deleting all cache entries in my os2.ini, all the random
WPS issues (disappearing objects, wrong paths, desktop not found, etc.)
have vanished. I'd have never thought in this direction.
Many thanks!
Felix Miata
> deleting all cache entries in my os2.ini
What's your procedure to do this? It's been years since I had a reason to
futz with OS/2's ini files.
Heiko Nitzsche
>
> What's your procedure to do this? It's been years since I had a reason to
> futz with OS/2's ini files.
Yes, me too (I'm still running eCS 1.15 since the first day
it came out) until I upgraded cairo several times and tried
the firefox betas. I have very many apps, drivers and fonts
installed and everything is highly efficiency optimized over
years :) . So I really was angry having to reinstall everything
because of the appearing WPS issues. The last weeks the system
basically survived only due to the desktop backups.
I had 5 font caches from different cairo versions in os2.ini
(version was coded in the cache app key), all most probably
containing the same data.
With regedit2 I simply deleted these app keys and my os2.ini
shrinked from 4.2MB to 3.1MB. checkini, which I normally use
from time to time, could of cause not find the problem. So
it seems WPS has serious problems with such big ini files.
But now, after the cleanup and some repairs with xfix (which
did not help before the cleanup), all seems to be fine again.
And thanks to the move of the cache to a different ini file,
there is a big chance it will stay so for a while :) .
Steve Wendt
>>> - Setting layout.css.dpi to 120. This corrects the font sizes used to
>>> display web sites, but not for the GUI.
>>
>>> - Add the following statement to userChrome.css
>>> * { font-size: 9pt !important; }
>> Previously, you said you needed 11pt (and 9pt should be the default) -
>> what's different now?
>
> I still do if layout.css.dpi is set to -1 or 96.
If it changes depending on the value of layout.css.dpi, which is not
supposed to affect chrome, then it definitely sounds like a bug. Could
you add that info to the Bugzilla bug? And especially note that you
need to specify what is already the default in order to get the right
size (assuming that is true?).
Peter Weilbacher
> No problems here. Great job, Peter and Doodle!
Great to hear that. :-)
> - De-install Innotek FT2LIB, remove any entries in INI files, re-install
> 2.60
But you know that FT2LIB isn't used by FF 3 any more, right? Or was this
just to clean up OS2.INI?
> With SDDFONTDPI=96 and SDDFONTSIZE=small, the fonts are still too small,
> but I can work-around the problem by:
>
> - Setting layout.css.dpi to 120. This corrects the font sizes used to
> display web sites, but not for the GUI.
Why do the web site fonts need correction at all? I thought they were
correctly sizes, with SDDFONTDPI=96 or without? Hmm, going through
Felix' screenshot in the bug it really seems that the content fonts are
always correctly sized (with FF 3).
Could someone open a bounty at OS2World to implement support for OS/2
bitmap font formats in FreeType? I tried this twice already but when
submitting my text always vanished. The admins either never got my mails
or ignored them. If we have that we could make some noise about it and
maybe finally someone steps up.
ste...@earthlink.net
at 10:14 PM, Peter Weilbacher <news...@weilbacher.org> said:
Hi,
>As you might remember, we first used the standard FontConfig on OS/2
>which uses XML-files (%HOME%\.fonts.conf) to store the font settings. We
>changed that to use the INI files, partly because users complained that
>XML file creation was too slow.
>Going to another INI file won't help anyway, as you can see in the
>threads about WarpIn corruptions in coo.apps.
Exactly. All the INI files share the same buffers in shared memory.
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net> MR2/ICE 3.00 beta 11pre13 #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------
Heiko Nitzsche
>> which uses XML-files (%HOME%\.fonts.conf) to store the font settings. We
>> changed that to use the INI files, partly because users complained that
>> XML file creation was too slow.
>
>> Going to another INI file won't help anyway, as you can see in the
>> threads about WarpIn corruptions in coo.apps.
>
> Exactly. All the INI files share the same buffers in shared memory.
Yes, maybe. But these INI files are only loaded as long as the
application runs while the WPS INI stays forever and affects
all other apps. That's why it is still valuable!
Peter Weilbacher
>>> Going to another INI file won't help anyway, as you can see in the
>>> threads about WarpIn corruptions in coo.apps.
>>
>> Exactly. All the INI files share the same buffers in shared memory.
>
> Yes, maybe. But these INI files are only loaded as long as the
> application runs while the WPS INI stays forever and affects
> all other apps. That's why it is still valuable!
Actually, since Doodle moved this to FCCACHE.INI, it will only be loaded
at application startup for a short while. So before Mozilla apps get
heavy on shared memory themselves. So in the end I think this is really
a change for the better.
William L. Hartzell
Peter Weilbacher wrote:
> On 20.06.08 23:20, Heiko Nitzsche wrote:
>>>> Going to another INI file won't help anyway, as you can see in the
>>>> threads about WarpIn corruptions in coo.apps.
>>>
>>> Exactly. All the INI files share the same buffers in shared memory.
>>
>> Yes, maybe. But these INI files are only loaded as long as the
>> application runs while the WPS INI stays forever and affects
>> all other apps. That's why it is still valuable!
>
> Actually, since Doodle moved this to FCCACHE.INI, it will only be loaded
> at application startup for a short while. So before Mozilla apps get
> heavy on shared memory themselves. So in the end I think this is really
> a change for the better.
At a little tangent, does any know if Cairo using apps like his screen
saver and Chris W.'s WPS Wizard will now have this fixed for them, or
even if this affected them?
BTW, even with this out of shared memory, I'm still having problems with
system INIs. So that bug is not this bug, sad face here.
Steve Wendt
> At a little tangent, does any know if Cairo using apps like his screen
> saver and Chris W.'s WPS Wizard will now have this fixed for them, or
> even if this affected them?
Until there's a new release of Cairo, it's still going to use the
"_for_Cairo" entry in OS2.INI.
Andy Willis
Yes, other apps will still be affected until either they or Cairo is
rebuilt using the new fontconfig (depending on how they are linked).
Andy
ste...@earthlink.net
at 11:20 PM, Heiko Nitzsche <hn-expire...@arcor.de> said:
>> Exactly. All the INI files share the same buffers in shared memory.
>Yes, maybe. But these INI files are only loaded as long as the
>application runs while the WPS INI stays forever and affects all other
>apps. That's why it is still valuable!
I agree with this. This is how I understand it is supposed to work.
The odd thing is that I've had application keys in private INI files get
replicated in OS2.INI after shared memory issue or Desktop hang forces a
reboot. The replicated key would not be unexpected if the application was
running at the time of the reboot. However, I've had this occur in cases
where the application has been closed for a long time prior to the reboot.
Of course, this may just mean that the WPS is able to limp along for
several hours until if gets to a totally unusable state.
Steven
--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net> MR2/ICE 3.00 beta 11pre14 #10183
Doodle
>> Actually, since Doodle moved this to FCCACHE.INI, it will only be loaded
>> at application startup for a short while. So before Mozilla apps get
>> heavy on shared memory themselves. So in the end I think this is really
>> a change for the better.
> At a little tangent, does any know if Cairo using apps like his screen
> saver and Chris W.'s WPS Wizard will now have this fixed for them, or
> even if this affected them?
FYKI:
I've just rebuilt the latest Cairo binary release (1.6.4) with the new
FontConfig code, and uploaded it to Netlabs:
ftp://ftp.netlabs.org/pub/Cairo/cairo-1.6.4-os2-bin.exe
(Please note that it has the same name as before, but contains updated
cairo dlls.)
The binary also has forwarder DLLs for older cairo dlls, so if one
installs this one, every old cairo using application (including
DSSaver's modules) will use the new FontConfig code.
Bye,
Doodle
William L. Hartzell
Thanks for doing this.