Just found the reason for facebook not working for me.
I didn't install the Tahoma font correctly, for some reason I couldn't find it / extract it, can't exactly remember now , so I renamed the tahoma.font file to _tahoma.font to prevent it's use. That was fine in the last version of OWB. Now it seems that OWB open every single font / otag and snoops for the .ttf files. Then tries to use them directly.
It doesn't check that the .ttf itself is present before using it!
Works okay here, gets all the way though, but reports LINKTEST ERROR. Oddly AWeb goes unstable just after though. Juat after OWB visited the site that is, normal they work togther fine.
Thanks for testing! LINKTEST ERROR is "normal" with OWB since I know OWB. I hadn't any problems at the acid3-test with the older OWB-versions. Strange!
I have a question since I haven't seen this mentioned anywhere. Sometimes when typing an URL and pressing enter nothing happens but clicking in the text field using the mouse pointer and pressing enter again solves it. Quite anoying though. Anyone else? A known issue?
For me it's happenes only for history. I.e. i press on url sttring, try to type some site, and nothink (i.e. i must type full domain name) if i press one more time by mouse, then 'history' is works, and url autoupdated and i have history link window.
Anyone else getting problems with the FaceBook login page with this version?
All the text input elements are really thin with no visable fonts. I couldn't loggin even by typing "invisibly" though that maybe because I couldn't see a typo to correct it.
Yes, It happened since 3.10 IIRC Its in the OWB bug tracker. I think it has something to do with the OWB TTF fonts as I've got them installed on the A1, but not on the A1200 with OS4. It doesn't seem to happen on the classic.
--edit--
Just deleted the corefonts on the A1 using typemanager and it made no differnce. login elements are still too small with no visible text in them.
Yet if I copy the same OWB folder over to the classic it works ?
Yes, It happened since 3.10 IIRC Its in the OWB bug tracker.
I can't reproduce it. Not with OWB 3.10, which still needed correct .otag files, nor with 3.13. It's working correctly with the core fonts installed and I just deleted all fonts but the DejaVu ones for testing and it's working correctly without the core fonts as well.
Without an archive of your, very likely broken, FONTS:#?.(otag|font) files, the output of "list FONTS:_TrueType" and the OWB Tooltypes you are using it's impossible to reproduce.
Quote:
I think it has something to do with the OWB TTF fonts as I've got them installed on the A1, but not on the A1200 with OS4. It doesn't seem to happen on the classic.
--edit--
Just deleted the corefonts on the A1 using typemanager and it made no differnce. login elements are still too small with no visible text in them.
Yet if I copy the same OWB folder over to the classic it works ?
OWB 3.13 doesn't need correct .otag files any more and builds the font families itself now because to much people use broken .otag files. It doesn't have workarounds for even more broken font installations like renamed .font/.otag files and I'll try to add some more workarounds, but I can't add checks for all possible font installation errors.
In my case I renamed the .otag file for tahoma to _tahoma.otag to prevent it's use as I new it was broken, (yet leaving there to remind me to fix it at some point)...
I notice that OWB scans every font in the FONTS: directory, even though you are trying work arroung the absense of fonts or the misnamedness (sic) of .otags files is that really a good idea? At the moment my A1 font directory is relativly sparse but my old A1200 directory was a lot fuller, scanning fonts in this way is going impinge on prgram startup time somwhat I would think.
When you scan the "broken" .otag files I would suggest the next step would be to check the .ttf file pointed to exists.
Or maybe just publish a list of .ttf files that must be in FONTS:__truetype and let the user sort it out. It seems like you are using the font directly amyway, to get access to the full character set.
Maybe it's not what you want to heard, but , i think you try to use ADSL modem with your os4.1 ? If yes, tcp stack will crashes a lot for you (better used router+local network).
In my case I renamed the .otag file for tahoma to _tahoma.otag to prevent it's use as I new it was broken, (yet leaving there to remind me to fix it at some point)...
Renaming .font/.otag files doesn't disable them, to remove a font from the system you have to move the files out of FONTS: into another directory.
Quote:
I notice that OWB scans every font in the FONTS: directory, even though you are trying work arroung the absense of fonts or the misnamedness (sic) of .otags files is that really a good idea?
It has to be done because of the wrong .otag files (without the font families set, which has to be done manually as TypeManager doesn't do it automatically when installing fonts) a lot of people are using.
Quote:
At the moment my A1 font directory is relativly sparse but my old A1200 directory was a lot fuller, scanning fonts in this way is going impinge on prgram startup time somwhat I would think.
It only opens outline fonts (fonts which have both a .font and .otag file), not bitmap fonts, and unless FONTS: is on a slow FFS partition and you have hundreds of fonts installed it shouldn't cause a noticable slowdown.
Quote:
When you scan the "broken" .otag files I would suggest the next step would be to check the .ttf file pointed to exists.
The next version will do that, but of course opening the .ttf (or .pfb/.afm) files additionally to the .font and .otag files will make it slower ...
Quote:
Or maybe just publish a list of .ttf files that must be in FONTS:__truetype and let the user sort it out.
The only fonts required by OWB are the DejaVu fonts included in AmigaOS 4.x, everything else, like the web core fonts most websites are using, is optional. But if additional fonts are installed which are used by a webpage they have to be installed correctly and work.
Quote:
It seems like you are using the font directly amyway, to get access to the full character set.
OWB doesn't access .ttf files (or the ones of other formats) directly, it uses the diskfont.library functions, for example if you just have a .ttf file without the .font and .otag files created by TypeManager it can't be used by OWB.
My fonts must have been broken. I moved out the complete contents of fonts: and copied the contents back from the A1 OS4.1 CD... Works now. I'll add my old fonts back one at a time. checking the family in type manager as i go.
No, OWB doesn't support it. But I've implemented it for the next version of the AmigaOS 4.x port.
Thanks a lot, joerg That will give great help for acessing amiga users modem for setings, for page with login+password for private page (beta software,....).
@kas1e
I'm using the same modem/router for my 2 amigas and all work fine. Just Ibrowse or OWB crash sometime but don't know if caused by OAS4.1 on the SAM.
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
That will give great help for acessing amiga users modem for setings, for page with login+password for private page (beta software,....).