I have fixed the Checkout text for NetSurf. It seems that <font color=white>Checkout</font> in the header made every further instance of font on the page default to white and not use the CSS font colour. This behaviour doesn't occur under Firefox or Odyssey.
I also added the message for NetSurf users to disable Javascript.
With respect to the MultiViewer problem: it worked fine here and I couldnt replicate it. No freezes on my X5000.
With respect to the MultiViewer problem: it worked fine here and I couldnt replicate it. No freezes on my X5000.
Odd. Hmm, it doesn't here either if I copy from amigans.net, but does if I copy from Google. (edit: actually, it seems quite random) (I was trying to save a copy from ClipView to make it easier to reproduce, but it saves as ASCII rather than FTXT)
@amikit By the way, you still can go the way as Hyperion do few days ago: uploaded as separate download changelog.guide. Probably, you need to do the same (i mean changelog.guide). Or at least some kind of .txt , where will be noted all changes of every component which do not contain sensetive information which you need to hold (through, i think no one care for those references to code, and that will be no problem to just copy+paste from svn commits).
I see on different forums as ppls like to download update1 for FE, and then download change log and checking this out. Enhancer for sure miss it and should be in imho. ("no time" excuse don't count :) )
What i mean, is that if you already spend so much on Enhancer, to not making changelogs its kind of make bad things at final, while almost everything important done.
For example still no one point us out on what changed or added in AmiPDF. Anyone ? Should we asking many times about as it was with Hyperion few years ago ?:)
For example still no one point us out on what changed or added in AmiPDF. Anyone ? Should we asking many times about as it was with Hyperion few years ago ?:)
At the bottom of the AmiPDF docs in the Enhancer package I see this:
However, I can tell you that I am able to open some PDF bank statements that don't work with the OS4.1FE AmiPDF. The old AmiPDF fails because the statementes use some newer fonts. It appears that the Enhancer AmiPDF is doing good font substitution or it includes newer fonts.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
However, I can tell you that I am able to open some PDF bank statements that don't work with the OS4.1FE AmiPDF. The old AmiPDF fails because the statementes use some newer fonts. It appears that the Enhancer AmiPDF is doing good font substitution or it includes newer fonts.
Apart from a rebuild of the XPDF core the changes in that version are largely GUI related. Therefore I would guess it's config thing, rather than any particular fix.
@broadblues In addition to now being able to read previously unreadable PDF files, small text in the Enhancer AmiPDF is almost unreadable. The kerning in really small text is horrible. Letters combinations like 'fi' an 'll' are blended together and the text is darker than with OS4 AmiPDF. I don't know if that's a font issue, anti-aliasing issue or Amiga display issue. Zooming to a larger size makes the text readable but the same small text in OS4 AmiPDF is clear. For now I'm keeping both versions. However, what I really want is an Amiga PDF reader that will work with the now common 'fill-in' PDFs.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
@broadblues In addition to now being able to read previously unreadable PDF files, small text in the Enhancer AmiPDF is almost unreadable.
Really? Please define "small" I just examined the front piece of a PDF doc with copyright text in small text in both the aeon amipdf and the hyperion amipdf and they are pixel for pixel identical.
To the point that I can overlap screen grabs and get a solid black rectangle when subtracking one from the other in SketchBlock.
Can you provide screens shots example PDFS your settings in both cases and other info to enable me to investigate your isue in more detail?
Quote:
The kerning in really small text is horrible.
AmiPDF does no "kerning", the position and spacing of glyphs is defined in the PDF by the application that created it.
If you are usng font substitution though fonts might not match the original spacing properly, so appear oddly spaced.
Quote:
Letters combinations like 'fi' an 'll' are blended together and the text is darker than with OS4 AmiPDF. I don't know if that's a font issue, anti-aliasing issue or Amiga display issue.
That does sound like aliasing or scaling issues.
Quote:
Zooming to a larger size makes the text readable but the same small text in OS4 AmiPDF is clear.
The only diference apart from GUI related stuff is a different freetype libray, that might account for the above, but I'm not sure why it differs for me, shouldn't be system dependent.
Quote:
For now I'm keeping both versions.
Certainly not a bad idea.
Quote:
However, what I really want is an Amiga PDF reader that will work with the now common 'fill-in' PDFs.
What is a 'fill in' PDF?
I have a port of XPDF 3.04 with partial hardware aceleration implemted but it's been on the back burner for a while, that does deal with a larger set of PDFS but it slow at the moment. The version of XPDF in the AEOn release is the same as the Hyperion one.
Really? Please define "small" I just examined the front piece of a PDF doc with copyright text in small text in both the aeon amipdf and the hyperion amipdf and they are pixel for pixel identical.
Okay slight retraction here, I was testing with my own build of AmiPDF. Which is 1.36 but I notice that 1.37 was the release version, testing with that I see markedly inferior font rendering. I didn't build that version. I think the only chnage relates to menu image size.
Rebuilding against latest svn my build which should be in sync with the released version is *still* at the same quality, pixel for pixel as the Hyperion version.
That is just plain odd, and needs investigation....
@xenic A bit (or not) offtopic, but give plz a try to vpdf port which i post in another thread. It use latest Poppler/XPDF/FreeType cores, as well as simple mui based interface, maybe it will worth of shot.
They are actually called "Interactive PDF Forms" that you can type into if using Adobe Acrobat. For example, my state tax forms are "Interactive PDF Forms" and on a Windows computer I can open the PDF, type the necessary data into the appropriate blocks and priint a completed tax return. I don't need to print the PDF and then enter the data with an ink pen. There are also some 3rd party Windows programs that let you enter data into a PDF.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
A bit (or not) offtopic, but give plz a try to vpdf port which i post in another thread. It use latest Poppler/XPDF/FreeType cores, as well as simple mui based interface, maybe it will worth of shot.
I'll try to get to it today but I'm a little bogged down with installing and testing FE update1, Enhancer update and other stuff.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
I think Multiviewer's text support has bigger problems. It freezes up on moderately large text files too, the likes of which display instantly in MultiEdit and Multiview.
Re MultiViewer: I have also noticed that in plain text files with tabs (typically: source code that uses deep level tab indentation), in deeper-nested tab-indented lines the first character after the tab gets swallowed. It may look like this: Picture
I think Multiviewer's text support has bigger problems. It freezes up on moderately large text files too, the likes of which display instantly in MultiEdit and Multiview.
Come Chris, your a developer, you know damn well that flimsy expressions like "moderatly large" mean nothing.
What size are the files 100k 500k 1Mb 10 Mb 1000Mb?
Are they ascii iso-#? utf-8 ?
Does the issue happen on every load?
Have you captured a serial log of the crash?
Was wordwrap on or off? (Is it the same in MultiView?)
Do these freezes happen when loading from an open window or only on startup or with tabs?
Do you get freezes with any other non image datatype? (sound, drawing, binary....)
Sorry for a false alarm - it's clearly a text.datatype bug, and is related to word wrapping. I had wordwrap off in MultiView so I had never spotted the bug. As soon as I turn it on, it demonstrates the same bug as in MultiViewer.