SumatraPDF is a lightweight Win32 pdf viewer app http://blog.kowalczyk.info/software/sumatrapdf/ http://code.google.com/p/sumatrapdf/
The name "sumatra" sounds weird (for an app), so I renamed the directory and the output exe file to "SmartPDF" (based on suggestions from #reactos).
SumatraPDF comes with VS 2k5 project files. I have fixed various compile issues so that libjpeg, poppler, fitz/mupdf and sumatra app itself compile without errors in mingw (RosBE 0.3.7.2 Win32). All code changes can be found by grep/search for "@note:", I added a comment to each changed code line.
The remaining problem is the linking issue. Currently it does NOT link correctly.
Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be related to the issue: "it [sumatrapdf] imports a function from winspool.drv by number, when you add that number to winspool.def, it starts"
Please have a look at it, fixes are appreciated :)
Klemens
I could resolve most of the linking errors by reordering the libs in the rbuild file. Yes, it does matter ;-) There are still 4 unresolved references left: `LaunchBrowser(char const*)' `_wstr_dup' `_WinMain@16' `_FT_Get_X11_Font_Format'
btw: is 'Kopie von SumatraPDF.cpp' still needed?
Timo
Klemens Friedl wrote:
SumatraPDF is a lightweight Win32 pdf viewer app http://blog.kowalczyk.info/software/sumatrapdf/ http://code.google.com/p/sumatrapdf/
The name "sumatra" sounds weird (for an app), so I renamed the directory and the output exe file to "SmartPDF" (based on suggestions from #reactos).
SumatraPDF comes with VS 2k5 project files. I have fixed various compile issues so that libjpeg, poppler, fitz/mupdf and sumatra app itself compile without errors in mingw (RosBE 0.3.7.2 Win32). All code changes can be found by grep/search for "@note:", I added a comment to each changed code line.
The remaining problem is the linking issue. Currently it does NOT link correctly.
Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be related to the issue: "it [sumatrapdf] imports a function from winspool.drv by number, when you add that number to winspool.def, it starts"
Please have a look at it, fixes are appreciated :)
Klemens _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
2007/9/30, Timo Kreuzer timo.kreuzer@web.de:
I could resolve most of the linking errors by reordering the libs in the rbuild file. Yes, it does matter ;-)
okay, I understand.
There are still 4 unresolved references left: `LaunchBrowser(char const*)'
... this one is a minor feature (launch a browser after clicking on a link), and I have commented it out for the meanwhile
`_wstr_dup' `_WinMain@16'
hm, don't know why
`_FT_Get_X11_Font_Format'
... is related to freetype, our freetype has only "FT_Get_X11_Font_Format" but none with leading underscore (ftxf86.c and ftxf86.h of freetype).
btw: is 'Kopie von SumatraPDF.cpp' still needed?
no, I deleted it plus some other unnecessary files
Klemens
Klemens Friedl schrieb:
`_FT_Get_X11_Font_Format'
... is related to freetype, our freetype has only "FT_Get_X11_Font_Format" but none with leading underscore (ftxf86.c and ftxf86.h of freetype).
The underscore is always added. The problem is that our freetype.dll doesn't export FT_Get_X11_Font_Format. But there's another problem: our freetype dll is a kernel mode dll linking to ntoskrnl.exe, so even if you could link the app, it wouldn't work. So you would first need to compile freetype as a static lib.
Timo
I have fixed all remaining linking issues EXCEPT one, the '_WinMain@16' issue.
[LD] output-i386\modules\rosapps\smartpdf\smartpdf.exe obj-i386\lib\3rdparty\mingw\mingw_main.a(main.o): In function `main': trunk/reactos/lib/3rdparty/mingw/main.c:73: undefined reference to `_WinMain@16' collect2: ld returned 1 exit status mingw32-make: *** [output-i386\modules\rosapps\smartpdf\smartpdf.exe] Error 1
The main function of SmartPDF/SumatraPDF:
int APIENTRY _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { ... }
... I have checked some other ros GUI apps like solitaire, which have the save definition, except "WinAPI" instead of "APIENTRY". Although using "WinAPI" there doesn't solve the issue.
Fixes for this mingw linking issue are appreciated.
Klemens
Klemens Friedl wrote:
SumatraPDF is a lightweight Win32 pdf viewer app http://blog.kowalczyk.info/software/sumatrapdf/ http://code.google.com/p/sumatrapdf/
But why this been imported into our repositry? What interest do we have in some 3rd party pdf reader?
It might help get it work ;-)
Ged schrieb:
Klemens Friedl wrote:
SumatraPDF is a lightweight Win32 pdf viewer app http://blog.kowalczyk.info/software/sumatrapdf/ http://code.google.com/p/sumatrapdf/
But why this been imported into our repositry? What interest do we have in some 3rd party pdf reader?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
But why this been imported into our repositry? What interest do we have in some 3rd party pdf reader?
The idea was to have some lightweight apps similar to the vision of Win95. All recent operating system have a PDF viewer as it's (beside DOC) the number one document format. My plan was to remove one of the pdf engines and add office format support (ole2, using libgsf library), so we would have a very lightweight document viewer app. An shell extention could then add preview & metadata of documents to explorer/shell.
I have also plans for a indexing service that provides system wide search and an interface to be compatible with MS iFilter, WordBreaker, etc. The current plan for such an indexing service is to use SQLite3 and CLucene. SQLite3 is a public domain very lightweight SQL engine that is used in a lot of software (I bet it is already in use on all of your computers and your cellphones, mp3 players, etc.). CLucene is a C++ port of the famous Java fulltext search engine. SQLite3 got a fulltext engine plugin itself, thanks to a google dev, called "FTS". It's currently limited but looks promising too. Of course, MS neither use SQLite nor CLucene for their indexer, but use their own database engine, based on SQL products that they have bought a long time ago. Writing a new database with fulltext support from scratch is not feasonable, and giving the fact that all recent software switched to SQLite (several new Microsoft software and games, google gears, new GMail, Google Reader, Google Desktop, Adobe Lightroom, several Apple software (coredata OS core lib, Spotlight search engine, iPhoto, etc.), I think it's ok to choose it.
An iFilter dll would use the pdf engine to extract the text and the metadata. I have planned to add some lightweight Win32 apps (E-Mail client, IRC client, PDF/Office-format viewer). As a PDF iFilter would be a needed anyway (at least in my opinion), so poppler is required too, and then a lightweight PDF viewer is just a matter of a few more source files. (currently, it consists of two pdf engines, one needs to be removed, one is optional anyway).
The overall goal is that is to have a handful of basic apps similar to Win95 (paint, email, etc.) and a system wide search that indexes several important formats (plugin based, with iFilter interface to be compatible with MS search products).
If a pdf vieweror a document viewer in general don't fit in "rosapps", then move it somewhere else, delete it or revert the commit(s).
If someone thinks that a indexer is not needed, and Google Desktop or any other third party desktop search engine is enough. Then you have probably never used a so called "desktop search". Please try out one, and you will see none of them even comes close to Apple Spotlight on MacOS X 10.4 (Tiger), and remember even Spotlight isn't that great (search results, boolean search), Google WebSearch is still a lot faster and delivers better search results. I am planning on the indexer for abouzt 1 1/2 years and the current status is that almost all third party libs compile with the reactos build environment in my local tree. Additionally, several test apps already work fine. One major issue is how to write the IDL for the iFilter interface. Another one is how to parse the search-input and send it to the right search engine and combine the results efficiently. But that's something for another ML-thread.
Klemens
On Monday 01 October 2007 06:30, Klemens Friedl wrote:
But why this been imported into our repositry? What interest do we have in some 3rd party pdf reader?
The idea was to have some lightweight apps similar to the vision of Win95. All recent operating system have a PDF viewer as it's (beside DOC) the number one document format. My plan was to remove one of the pdf engines and add office format support (ole2, using libgsf library), so we would have a very lightweight document viewer app. An shell extention could then add preview & metadata of documents to explorer/shell.
I have also plans for a indexing service that provides system wide search and an interface to be compatible with MS iFilter, WordBreaker, etc. The current plan for such an indexing service is to use SQLite3 and CLucene. SQLite3 is a public domain very lightweight SQL engine that is used in a lot of software (I bet it is already in use on all of your computers and your cellphones, mp3 players, etc.). CLucene is a C++ port of the famous Java fulltext search engine. SQLite3 got a fulltext engine plugin itself, thanks to a google dev, called "FTS". It's currently limited but looks promising too. Of course, MS neither use SQLite nor CLucene for their indexer, but use their own database engine, based on SQL products that they have bought a long time ago. Writing a new database with fulltext support from scratch is not feasonable, and giving the fact that all recent software switched to SQLite (several new Microsoft software and games, google gears, new GMail, Google Reader, Google Desktop, Adobe Lightroom, several Apple software (coredata OS core lib, Spotlight search engine, iPhoto, etc.), I think it's ok to choose it.
This triggered a memory: Managing Gigabytes (text searcher and indexer): http://www.ncsi.iisc.ernet.in/raja/netlis/wise/mg/mainmg.html http://www.cs.mu.oz.au/mg/ http://www.cs.mu.oz.au/mg/preface.html
And a text search engine (not an indexer): http://www.cs.mu.oz.au/~oldk/seft/
You might like to take a look at them.
Wesley Parish <snip>
If someone thinks that a indexer is not needed, and Google Desktop or any other third party desktop search engine is enough. Then you have probably never used a so called "desktop search". Please try out one, and you will see none of them even comes close to Apple Spotlight on MacOS X 10.4 (Tiger), and remember even Spotlight isn't that great (search results, boolean search), Google WebSearch is still a lot faster and delivers better search results. I am planning on the indexer for abouzt 1 1/2 years and the current status is that almost all third party libs compile with the reactos build environment in my local tree. Additionally, several test apps already work fine. One major issue is how to write the IDL for the iFilter interface. Another one is how to parse the search-input and send it to the right search engine and combine the results efficiently. But that's something for another ML-thread.
Klemens _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Ged -
Klemens Friedl -
Timo Kreuzer -
Wesley Parish