AROS World Exec
Development => Development (General) => Topic started by: watto on November 11, 2018, 03:56:04 AM
-
Hello there,
Just thought you guys may be interested in some vpdf progress.
There are plenty of issues still, but I seem to have figured out why it was crashing... seems to be connected to truetype fonts. Seems to crash whilst reading them in, but could be connected to rendering also. This is building ok on ABI 1 using normal mmake script, I think on ABI 0 there'll be some issues with the MUI child lookups, but haven't checked just yet.
If anyone would like to help me out with some ideas on this, please let me know. Otherwise I'll keep hacking away at it until we hopefully get something usable. Worst case I'll see if some of the improvements can be brought over to AROSPDF.
If it helps, I'm the guy who did the original AROSPDF (about 10 years ago), and a few other things. It's been a while since I've worked on AROS/Amiga, pretty rusty, but I hope I can get a couple things done at least. I've got a list of things I'd like to port/fix, time permitting.
-
Hi watto,
thanks for your effort.
I compiled Odyssey with ABI_V0 and I also noticed the crash while opening forms with child lookup (Bookmarks and Cookie). Please keep me posted if you fix the issue. Of course if I'll do the same with you if I have news on this topic.
Cheers
-
hi watto
it would be good to fix this up. we were looking at it with neil and afair he came to similar conclusion. commenting out some section of code retated to fontconfig, which i dont rememeber, i might be able to recall though, made it work on abi v1 386 to an extent, has though never worked for other platforms at least big endian ones.
i thought btw, arospdf was more advanced, and it works too, but it might be worthwhile to check up vpdf as well, and review whatever i have commited if it holds any water.
-
Does it use MUIM_Family_GetChild or MUIM_Group_GetChild? These didn't seem to do anything under ABI 0, at least whichever version of it I had under icaros. I could find items by iterating through the ChildList instead but not 100% on whether that was getting the right data either.
If I can get vpdf working right on ABI 1, I'll try to port it back to ABI 0 - obviously other issues in vpdf at the moment and it may well just have been those causing the crashes.
There are also some uses of InitChange in vpdf code that aren't checking for the result, which I don't think is the best behaviour, maybe was done to get past some failures though.
-
AROSPDF uses the Splash backend vs Cairo in vpdf and is build off of xpdf vs Poppler which is newer and probably a bit better for newer PDF versions. Aside from that there are several features in vpdf that would take some time to re-implement in AROSPDF.
If I was to re-do AROSPDF I'd want to use Poppler and Cairo anyway. Ideally we could pull Poppler out into a library or DataType or something ridiculous but I'd have to leave that to someone who knows what they are doing :)
When I did AROSPDF there wasn't any proper PDF viewer in AROS (no offence to PoorPDF), it was pretty much a quick and dirty MUI front-end to xpdf with most stuff stripped out. I then got busy at work, moved countries, got married, bought a house, renovated it, sold it, finished a University degree and moved countries again, so pretty much had no time to support it and ScummVM, etc. that I had been working on. I'll hopefully have more time to keep things maintained now.
-
i applaud your effort. in fact the inability to finally fix up vpdf as well as few other (mostly mui/zune frontend equipped) contribs (for differnet reasons) has been driving me nuts. ill try to be of as much assistance as possible, but im not sure if i can competently help and answer your questions especially where aros internals are considered, as im not or a very lousy coder, at best.
best is to as questions on aros ml. or for fast interaction (hopefully) join a slack chanel. as i proposed elsewhere. pm me with your email if you are interested and ill invite you there.
-
Thanks watto, I hope you can also take a look at soundfx is a tool for mmusicisti that would come in very useful ;)
salvatore
-
This has been a productive day :) Fonts are working. Main issue was an enum that defined some names with the same values as some char constants used by fontconfig. The fonts were using the char constants to look up values in an array - obviously the indexes were way off what they should've been causing the crashes. If there weren't so many warnings already I'd probably have noticed it before.
Still some issues with thumbnails, a couple UI functions not working, but as you can see it's displaying PDFs fine.
-
And proof the fonts work correctly (I think) now...
-
This has been a productive day :) Fonts are working. Main issue was an enum that defined some names with the same values as some char constants used by fontconfig. The fonts were using the char constants to look up values in an array - obviously the indexes were way off what they should've been causing the crashes. If there weren't so many warnings already I'd probably have noticed it before.
Still some issues with thumbnails, a couple UI functions not working, but as you can see it's displaying PDFs fine.
Ooooo thanks for work :)
-
@watto:
is it for abi V1 32 bit or 64 bit ?
I see that the colors are not correct; endianness issue maybe ?
-
32bit - images are from linux-i386 hosted. Not sure if there'd be any issues with it working on 64bit.
Once I've fixed the remaining issues and cleaned up all my unnecessary hacks and debug output I'll get a diff up and binaries for testing, then look at building on ABI 0. I expect some MUI problems on ABI 0 - was trying to build it on there before and had to add quite a few workarounds for it and code commented out.. I'll try removing the fonts on there and see if it magically starts displaying stuff - if that works, good chance it just needs my changes and maybe a couple features taken out or re-implemented.
Not 100% on the ABI v0/1 situation, looks like we're on a 2016 branch for v0? Fairly sure I've lost my SVN access anyway so I'll need to fix that up so I can push stuff back.
-
32bit - images are from linux-i386 hosted. Not sure if there'd be any issues with it working on 64bit.
Once I've fixed the remaining issues and cleaned up all my unnecessary hacks and debug output I'll get a diff up and binaries for testing, then look at building on ABI 0. I expect some MUI problems on ABI 0 - was trying to build it on there before and had to add quite a few workarounds for it and code commented out.. I'll try removing the fonts on there and see if it magically starts displaying stuff - if that works, good chance it just needs my changes and maybe a couple features taken out or re-implemented.
Not 100% on the ABI v0/1 situation, looks like we're on a 2016 branch for v0? Fairly sure I've lost my SVN access anyway so I'll need to fix that up so I can push stuff back.
abi v0 is becoming obsolete; abi v1 is the main branch and we should gradually move to it, finally abandoning abi v0.
-
Appreciate what you're saying, but most of the existing software and distros are for ABI 0 as far as I know.
I already develop for ABI 1 first. I'll aim to make my work available for both for now.
-
@watto
Thank you very much!
-
did a program written in Hollywood RNOPDF but there is no version for aros, I find this strange thing ???
salvatore
-
Appreciate what you're saying, but most of the existing software and distros are for ABI 0 as far as I know.
I already develop for ABI 1 first. I'll aim to make my work available for both for now.
Thanks a lot for your work. Realy good you understand the ABI situation. We all wish we could have abandoned abi v.0 by now but it is not
that simple. We talked about this many times and the natural way is to go ABI v.1 with AROS64. Everything for ARM or AROS 68k is ABI v.1 already.
AROS i386 32-bit will probably stay ABI v.0 for many reasons.
-
did a program written in Hollywood RNOPDF but there is no version for aros, I find this strange thing ???
salvatore
Unucliky, it seems polybios for AROS has some limitation due to a missing C++ compiler. It can create PDF files (and, in fact, RNO Effects correctly creates them), but it cannot, de facto, read them.
-
This is from Hollywood FAQ:
Q: Why doesn't Polybios support the conversion of PDF pages to vector
brushes on AROS?
A: That's because PDFium requires a compiler capable of handling C++11 and
wide characters which is currently unavailable for AROS. But this will
hopefully change in the future so that AROS users can convert PDF pages
into Hollywood brushes too.
-
ompiler capable of handling C++11
we have such compilers, if only not for abiv0, perhaps.
-
Thank you paolo i understand
salvatore
-
ompiler capable of handling C++11
we have such compilers, if only not for abiv0, perhaps.
I built a C++11 cross-compiler (GCC 4.8.3) recently, so ABIv0 is definitely not lacking on that front.
-
That‘s what I expected too. ???
ompiler capable of handling C++11
we have such compilers, if only not for abiv0, perhaps.
I built a C++11 cross-compiler (GCC 4.8.3) recently, so ABIv0 is definitely not lacking on that front.
-
I already develop for ABI 1 first. I'll aim to make my work available for both for now.
a very good approach. building with aros toolchain makes it anyway less complicated to develop for v1 while keeping v0 up and allowing for multiple target archs imho.
-
you should contact the author of the program, I refer to RNOPDF and clarify this, maybe bring the program on aros
-
i send a message
hi
-
I am in contact with the author of both RNO REffects (I sincerely hope you're enjoying this program as I am), and RNOPDF. I am just quoting his explanation, which was in turn quoted from Polybios FAQ.
If we have such a compiler, we definitely have to advice POLYBIOS author, not RNOPDF one.
I'll try to bring things together.
-
ok thank you Paolo
salvatore
-
I am in contact with the author of both RNO REffects (I sincerely hope you're enjoying this program as I am), and RNOPDF. I am just quoting his explanation, which was in turn quoted from Polybios FAQ.
If we have such a compiler, we definitely have to advice POLYBIOS author, not RNOPDF one.
I'll try to bring things together.
On Aros 68k RNOPDF already works
-
On Aros 68k RNOPDF already works
Which is good in absolue but - IMHO - quite saddening from another point of view. We should catch up with that, really, on i386.
-
On Aros 68k RNOPDF already works
I tried it. I can read text, which is properly formatted, but no image is rendered on the pages. This under AROS M68K.
-
And proof the fonts work correctly (I think) now...
Very good.
I noticed we've hijacked your vpdf topic with RNOPDF things... Please excuse me.
Keep up the great work.
-
I've never had problems with arospdf, maybe the interface could improve thanks anyway ;)
-
Just a quick update.
Some further issues due to MUI differences. Trying to fix these up - if anyone has a good hack for tab buttons (MUIC_Title doesn't work) let me know.
I'm trying to get outlines working with NListtree and trying to fix up search. In text links work (eg. contents page) but seem to be directing the thumbnails and not the main view.
Hopefully have something for the weekend so I can start work on something else :)
-
@watto
do you have full access to aros svn repo to commit your changes? i think neil is in charge of privileges.
-
Not as yet wawa, I'd like to make some more progress before I organise anything.
Fixed up some weird tab behaviour (things loading in to the wrong child object). The thumbnails and outline are now a RegisterGroup although this was probably not necessary so may be able to back that one out... Colour weirdness is sorted (endianess issue - may be a problem on big endian now.)
Still to go:
1. Hook that populates the Outline text - still not working although the outline and tree itself does, just get garbled text.
2. Scrollbars disappearing or not appearing
3. Some weirdness with larger files and continuous layout modes and page numbers/scrollbars getting messed up
4. Search/copy paste (mainly text/charset conversion related)
5. Alternatives for close button on each tab (unsupported on AROS's MUIC_Title) and add back save option
6. General improvements, UI balancing, etc.
7. Alternative way to select document sizing mode (fit to window, page, etc. options)
It's reliably opening files, tabs are behaving properly, just a few more things not quite right
-
would though be good not to hard code endiannes from the start. you certainly know, aros has macros for that.
-
Oddly enough it seems that Cairo causes it - the code has requested a Cairo surface ARGB but is storing BGRA. WritePixelArray is expecting ARGB. Should be able to work with it anyway of course.
I guess this isn't a problem for the existing ports on Morphos and OS4...
-
we do have big endian targets also on aros: m68k (my favourite), ppc and incoming big endian arm/raspi.
you can send me a patch if you need testing on other platforms, pixel formats or endians.
-
@watto
thank you so much
hi
Salvatore
-
Still working on this when time permits.
From the list above:
1. Outlines - sorted.
2. Scrollbars issue seems to be related to 3
3. Weirdness with larger files - this appears to be caused by MUIA_Height returning signed 16-bit values rather than proper 32-bit longs. An overflow occurs which causes values to flip around and some incorrect pages are then displayed (because the values wrap around and the page view thinks they should be visible.) This is only an issue on very large PDF files - I have a Korg Kronos manual PDF that triggers the issue reliably. Would be nice if someone else who likes MUI/Zune could confirm whether what I'm seeing here is happening elsewhere. I'm working on some code to deal with this myself and bypass MUIA_Height but it needs more work. This also seems to be confusing scrollbars, causing them to display improperly, etc. which is to be expected I guess.
4. Search - still broken. Copy/paste - now sorted.
5. Close Tab in the menu now. Save has been added back to the menu also and seems to work.
6. Still need to work on UI balancing, the outline/thumbnails tab always opens at around 50% for some reason.
7. Document sizing - looking to fix this next.
Given the amount of changes and hacks I have made so far, it's probably easier for me to put the changes up on GitHub or similar for the time being as it'll take some time to add back in all the #ifdefs and refactor some of the hackier parts. So I may do this in the short term so others can look at it and try build it, etc.
The main missing functions - the sizing toggle option and the search are things I want to fix before releasing tests. The other issues can be worked around/avoided. So hopefully some binaries/code soon.
-
thank you watto :)
-
Very good! Thank you, watto! :D
-
@watto
if you going to commit to aros repo you might face some changes i introduced, mostly minor, casts and the like to satisfy paranoia on newer compilers such as gcc-6 as well as changes getting vpdf at least start at m68k, (probably mui/hooks related, i dont remember well, but the commit history will). please consider them and leave them intact/or merge them (if they are correct) to keep m68k and big endian as viable target.
-
@watto
have you now resigned or whats up? i am currently trying to get your version of vpdf contained in contribs 64 bit safe and i could really need some assistance on two or three issues i have discovered. i think you might also take advantage of the 64bit fixes, extended vapor.h or m68k fixes to mui frontend that have been incorporated in the controb/vpdf source. you could join us on slack...
-
@wawa Very sorry, I've become rather busy again and I appear to have lost my VM somewhere... I am just now trying to pick things up again as it has been a couple months since I've had a bit of free time to look at this.
Did you grab my code from github? https://github.com/wattoc/AROS-vpdf
There were a couple issues remaining and I think last time I looked I was trying to get a 64-bit environment up and going. The main thing missing now as far as I remember is a set of buttons to toggle view mode. Otherwise I think I have got most of the things in that list fixed other than the MUI size issue which is probably better dealt with at the source.
The plan was to grab a copy of the latest tree and then merge my changes in to that carefully - I had spent some time trying to ditch some of the debugging code, etc and get things as close to the original as possible. I think the biggest code issue would be the hacks I made to deal with namespace problems, most of the other code is really MUI specific and should hopefully port over fairly cleanly but could do with some more IFDEFS, and so on, so we are not too far from the original.
Please drop me a message on here or an email if you think I can help. I probably won't have time to spare to hang about on slack for quite a while unfortunately, but I'll see what I can do.
-
@watto
you have pm, in case you havent noticed. ill apply (a choice of) your changes soon into my aros fork and test. i can hopefully distinguis between mui chanes, intermediate debug and fontconfig related stuff.
-
@wawa - I did reply to your message, or at least I thought I did. Summary of it is below:
I have 64-bit up and running on my VM that I had lost, and it will need merged with your code as there are quite a few pointer cast issues in mine as expected.
I think the best process would be to get things merged in and running, then we can look at adding in any remaining missing features.
I'm happy to work with you on this, it sounds like we are probably doing similar things right now. If you manage to get something up and going in the meantime please let me know and I'll try to progress things further from there. I'd still like to finish it, it's just a question of how much time and energy my day job takes from me :)
The main thing will be how compatible with the existing source we want to be, ideally most of my changes can be ifdef'd in to the existing code. Since it was WIP there are probably quite a few hacky bits where I have just inserted or deleted bits of code which I would prefer are fixed properly, but I'm not sure where the team stands on this sort of thing.
-
hm. i dont see any pm from you in my box. so the forum remains. ill be trying to merg your changes one by one, but need to take care of pretty unrewarding daily tasks.
-
one of the questions, shouldnt we keep the code also morphos compliant since i see you have removed
#include "GlobalParamsMorphOS.cc" from GlobalParams.cc
maybe every platform could include their solution at this point?
-
/home/wawa/AROS-git/AROS/contrib/vpdf/poppler/poppler/GlobalParams.cc:127:6: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
127 | {"Courier", "n022003l.pfb", "cour.ttf"},
| ^~~~~~~~~
/home/wawa/AROS-git/AROS/contrib/vpdf/poppler/poppler/GlobalParams.cc:127:31: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
127 | {"Courier", "n022003l.pfb", "cour.ttf"},
| ^~~~~~~~~~~~~~
....
-
i have silenced the above complaints for convenience.
@watto
so far i have merged in your fontconfig changes, save some debug and a bit of formatting, beacuse i didnt wanted to mess with poppler inrternals too much as it aint our code, right? so i thought it would be ideal to outsource it to a separate source file as morphos team did just to keep our diffs maintainable in case we wanted to upgrade to never code.
so far the fontconfig problems on i386 went away and it displays the test files. the mui interface is of course still borked, as im going to merge it in later after i reviewed the changes and perhaps keep it in separate commits.
for now i need to compile few other targets.
-
@watto:
what causes crashes on x86_64 is, first of all
line 124 in printer.c:
Child, (IPTR) RawimageObject, MUIA_Rawimage_Data, (IPTR) Printer, End,
and then subsequently:
line 544 in application.c:
ASLFR_InitialFile, msg->initialfile ? msg->initialfile : msg->initialpath ? (char*)FilePart(msg->initialpath) : (char*)"",
with these commented out vpdf opens on x86_64 but then still fails to load test file:
...
[Process.mui] my_process called
[Process.mui::my_process] data 00000000443a6990 sourceclass 0000000044361080 sourceobject 00000000443612b8
[Process.mui] my_process called
[Process.mui::my_process] data 00000000443a6a70 sourceclass 00000000435f13a0 sourceobject 00000000442527e8
[Listtree] OM_NEW: unhandled 80004001
[MUIM_Process_Signal] sigs 8192
[convertUTF32ToANSI] not implemented
[Pageview::Hide] not implemented
cleanup:1
[Pageview::Hide] not implemented
cleanup:1
[KRN] Trap signal 11, SysBase 0000000042f3d820, KernelBase 0000000042f3ea08
RSP=00000000439a5fa8 RBP=00000000439a6010 RIP=0000000043ae4980
RAX=0000000043ae4980 RBX=000000004422d0d0 RCX=0000000000000000 RDX=0000000000000000
RDI=0000000000000000 RSI=0000000000000000 RFLAGS=0000000000010246
R8 =00000000446d1850 R9 =0000000000000000 R10=0000000000000002 R11=0000000000000000
R12=0000000000000000 R13=0000000000000000 R14=0000000043a5bfb0 R15=fffffffffffffff8
*** Logged alert:
Program failed
Task : 0x00000000435F14E0 - System:Extras/Utilities/Text/VPDF/VPDF
Error: 0x80000002 - Hardware bus fault/address error
PC : 0x0000000043AE4980
Module VPDF Segment 1385 .text (0x0000000043A3EAE0) Offset 0x00000000000A5EA0
Function _ZN4Page9getAnnotsEP4XRef (0x0000000043AE4980) Offset 0x0000000000000000
CPU context:
RAX=0000000043AE4980 RBX=000000004422D0D0 RCX=0000000000000000 RDX=0000000000000000
RSI=0000000000000000 RDI=0000000000000000 RSP=00000000439A5FA8 RBP=00000000439A6010
R8 =00000000446D1850 R9 =0000000000000000 R10=0000000000000002 R11=0000000000000000
R12=0000000000000000 R13=0000000000000000 R14=0000000043A5BFB0 R15=FFFFFFFFFFFFFFF8
RIP=0000000043AE4980 RSP=00000000439A5FA8 RFLAGS=0000000000010246
Stack trace:
0x0000000043A634B3 VPDF Segment 1385 .text + 0x00000000000249D3
0x0000000043A63ADD VPDF Segment 1385 .text + 0x0000000000024FFD
0x000000004366180E muimaster.library Segment 1 .text + 0x0000000000013D4E
0x0000000043663136 muimaster.library Segment 1 .text + 0x0000000000015676
0x0000000043664964 muimaster.library Function Application_Dispatcher + 0x0000000000000F64
0x0000000043A48757 VPDF Segment 1385 .text + 0x0000000000009C77
0x0000000043A4035B VPDF Function main + 0x0000000000000B7B
0x0000000043A3EC3D VPDF Segment 1385 .text + 0x000000000000015D
0x0000000043D7BCB5 VPDF Segment 1385 .text + 0x000000000033D1D5
0x0000000043D7C6AA VPDF Segment 1385 .text + 0x000000000033DBCA
-
im still not sure if the above is vpdf or aros infrastructure itself at fault. have been debugging this (asl requester) but im too inexperienced to come to a conclusion.
-
Is this work committed or just in your own workspace?
-
@watto:
i have a fork of aros contrib in my own repo:
https://github.com/wawatok/contrib/commits/vpdf-update
as you may see i just pushed the font stuff and made a pull request for the main aros github repo.
im just merging the mui stuff. ill see how it works and have eventually a small mostly rather formatting related diff for you, except replacing long with LONG type in few places.
also i have left out most of debug for now where i felt it may not be required afterwards.
however im not ready with mui just yet.
-
@watto
okay. merged in i think most of the mui changes. i have left out the codesets ifdef for aros in wincow.c. but it seems vpdf gui works now correctly what concerns tabs. at least at the firts glance.
the problems i reported above for x64 still remain open of course. and there is a lot of warnings when compiling which i have been attempting to fix in my local copy and i will provide you with an appropriate diff when merging in your code is complete.
btw, here is the crash that follows asl issue on x64:
[KRN] Trap signal 11, SysBase 0000000041a05820, KernelBase 0000000041a06a08
RSP=000000004246d328 RBP=000000004246d380 RIP=0000000044b218a0
RAX=0000000044b218a0 RBX=0000000041a51510 RCX=0000000041a51510 RDX=000000004246d630
RDI=0000000043088b20 RSI=0000000000000001 RFLAGS=0000000000010202
R8 =000000004246d2b0 R9 =0000000041a05820 R10=0000000000000000 R11=0000000000000001
R12=0000000042222f18 R13=0000000041aa5c40 R14=000000004246d400 R15=0000000042222f98
*** Logged alert:
Program failed
Task : 0x00000000420B2420 - System:Extras/Utilities/Text/VPDF/VPDF
Error: 0x80000002 - Hardware bus fault/address error
PC : 0x0000000044B218A0
Module intuition.library Segment 1 .text (0x0000000044AEB7A0) Offset 0x0000000000036100
Function strcpy (0x0000000044B218A0) Offset 0x0000000000000000
CPU context:
RAX=0000000044B218A0 RBX=0000000041A51510 RCX=0000000041A51510 RDX=000000004246D630
RSI=0000000000000001 RDI=0000000043088B20 RSP=000000004246D328 RBP=000000004246D380
R8 =000000004246D2B0 R9 =0000000041A05820 R10=0000000000000000 R11=0000000000000001
R12=0000000042222F18 R13=0000000041AA5C40 R14=000000004246D400 R15=0000000042222F98
RIP=0000000044B218A0 RSP=000000004246D328 RFLAGS=0000000000010202
Stack trace:
0x00000000421BA11A asl.library Function AslString__OM_NEW + 0x000000000000004A
0x0000000044AF495B intuition.library Function Intuition_106_NewObjectA + 0x000000000000007B
0x00000000421AC2AB asl.library Segment 1 .text + 0x00000000000066EB
0x00000000421AD067 asl.library Function FRGadgetryHook + 0x0000000000000087
0x00000000421A7080 asl.library Function Asl_10_AslRequest + 0x0000000000000130
0x000000004257BD8A VPDF Segment 1385 .text + 0x0000000000004C9A
0x000000004257F1C9 VPDF Segment 1385 .text + 0x00000000000080D9
0x0000000042581782 VPDF Segment 1385 .text + 0x000000000000A692
0x000000004257E1C5 VPDF Segment 1385 .text + 0x00000000000070D5
0x00000000425816A4 VPDF Segment 1385 .text + 0x000000000000A5B4
-
@watto
here are my mostly cosmetic proposals for your consideration, however there might be some type corrections and the like.
-
because it may not hurt i also attach the 64bit fix proposals diff.
note that im not a coder so this needs a proper review.
-
i think ill commit and push the mui updates now to my repo.
-
i have silenced the above complaints for convenience.
Did you do that by suppressing the warning?
If yes, just for completeness, the correct way would be to declare the struct/class member to be a 'char const*' so you get a diagnostic message if someone later attempts to actually write into it, rather than (possibly) crash at run-time (now or later).
If not, please disregard, I do not have any fix to look at(?)
-
yes, i suppressed it for the time being, because i would like to synchronize the aros repository with the authors first. and yes, i think this is probably the fix as hinted at by gcc9, but thx anyway. hope watto corrects that.
-
@wawa I'll be looking at your changes along with what I have and double check whether anything I think important has been lost. I agree with you regarding retaining compatibility with MorphOS and others so will look at doing that as well as finding the source of the crash.
-
I've made some updates to my GitHub repo: https://github.com/wattoc/AROS-vpdf
I do have a mostly working VPDF on x64 ABI v1 at this point, but there are still issues with some select files. There's a problem with fonts for some PDF files where it'll crash AROS. If you open another PDF first (eg. the test one that checks the fonts) it'll actually then load that problem file OK. I think this is down to FontConfig/TT.lib in AROS itself rather than something within VPDF, perhaps something being accessed before it should be and only specific files can trigger it. The problem file has embedded fonts. I did add a bunch of logging to try to track it down but I'm coming up a bit short. For what it's worth I think I had to statically link some libraries in AROSPDF for the exact same issue.
I've been working on this sporadically but to be honest it doesn't especially interest me right now, and I'll probably have to move on to something else as it's just too much fiddling around to get things going - I don't find the whole dev environment especially productive, it's just not a great set up for someone trying to develop actual applications for a system although I'm sure others will tell me I'm wrong there. MUI isn't really my forte either and someone who knows it better should probably try to improve the UI a bit.
Someone else should probably look to pick this up but I may spin it up again for a look now and then, if I'm feeling a bit masochistic.