Hallo,
Ich habe mich dem Thema auch beschäftigt.
Es gibt eine Reihe Kommersielle, die dafür Geld verlangen. OK! Wieso nicht?
Von den anderen habe ich folgende ausprobiert:
iText, Acrobat Viewer Bean, PDFBox - alles Java.
--iText  kann gar nicht Images erstellen. Es beschäftigt sich auch wenig mit der Ausgabe. Bei PDF erstellen ist es aber wirklich OK!
--Acrobat Viewer Bean(AVB) ist eine Entwicklung seit 1999. Es ist ein JAR dabei. Der Sourcecode ist nicht vorhanden. Von den Beispielen lässt sich nachvollziehen vie man ein "java.awt.Image" erstellt und durch "javax.imageio.ImageIO" ein JPG oder BMP gespeichert wird. Leider reicht die Qualität nicht aus!
--PDFBox ist Open Source. Unter anderen, ähnlich wie bei AVB, lassen sich JPGs & BMPs erstellen. Die Qualität ist besser als AVB, aber leider nicht ausreichend! Es gehen manchmal auch simple Grafiken verloren.

Lt Adobe, ein PDF SDK wird frei zur Verfügung gestellt, aber dafür muss man sich bewerben ud ich habe seit 5 Monate kein Antwort. Dort wird man auch zu der Site von einer USA Fa verwiesen, die für nur 20 000$ eine JAVA/C++ Schnittstelle auf das PDF Kit anbieten. Man kann eine trial Version anfordern. Ich habe mir das auch kurz angeschaut und habe das Verdacht, dass der Adobe PDF Kit in C++ Source vollständig auch dabei ist...keine Garantie und keine Haftung für diese Aussage!
Fazit: Ghostscript!Ghostscript!Ghostscript! Die PDFs, die ich ausprobiert habe waren in sehr guten Qualität konvertiert.

Viel Spass!

Ich hab jetzt das "basic.rc" gelöscht und dafür "pdf2any.rc" angelegt. Dort habe ich dann auch gleich noch ein Icon festgelegt, so dass das .exe File nicht immer das Default Icon hat. Das Icon heisst "pdf2any.ico" und stellt ne kleine Ameise mit Surfbrett dar. Hab im Moment kein besseres gefunden. Du kannst ja auch mal schauen, ob dir hier ein besseres gefällt:
http://www.iconarchive.com/

Hab das .msp und .dev File angepasst und die "_private" Files und ".Manifest" gelöscht.

Zu 1:
Ja, dann legen wir jetzt fest, dass wir zum Einrücken nur Spaces nehmen und zwar genau 4 Stück.

Zu 2:
Da hast du Recht. Manche Sachen dort sind wirklich nicht schön. sowas würde ich auch alles in eine Zeile schreiben. Ausser es sind mehr als ca. 3 Parameter da, dann würde es die Parameter untereinander schreiben:


Zu 3:
Ja, bei Funktions-Definitions-Blöcken würde ich die geschweiften klammen auch in die nächste Zeile am Anfang und nicht ans Ende stellen. Aber bei den if, while, for, switch, do-while, ... würde ich das so machen wie bei dem Coding style beschrieben.
Bei dem erwähnten Konstruktor bin ich leidenschaftlos, den kannste so lassen.

Zu 4:
Hmm. Da habe ich im Moment noch keine Idee. Muss mal überlegen. Es sollte halt ein default Wert geben (z.b. 300) und in der GUI sollte es schon ein Options-Panel geben, wo in einer Combox alle möglichen werte aus dem XML angezeigt werden (in XML Komma-getrennt und erster Wert ist Default). Irgwendwie so.

Zu 5:
Ja, wir sollten umstrukturieren. Wir entwicklen ja keine API, also hast du recht, dass wir keinen include ordner brauchen. Das heisst im "src" liegen alle .cpp (wir programieren C++, also sollte wir alle .c File in .cpp umbenennen) und .h (ich hasse die Erweiterung .hpp, deswegen lasse ich das normalerweise bei .h auch wenns c++ ist) Files.
Das .rc File (ich denke .rc gibt es nur auf Windows) und das .ico File (Programm Icon), dass im .rc file festgelegt ist kann doch im Hauptordner bleiben oder ? Oder vielleicht im ordner "resources" ?
Language files würde ich vielleicht in einen "lang" Ordner und dann darunter in die jeweiligen "de_DE", "en_GB" , ... ablegen.

Umstruktieren, ohne Historie zu verlieren ist schon echt unmöglich mit CVS. Geht das mit SVN ? Du würdest also von Sourceforge weggehen und die Sourcen bei diesem opensvn ablegen ? Oder vielleicht nur die Programm Releases und Sources jeder Version als Zip bei Sourceforge ablegen.

Wegen dem delete m_logger:
Dann schieb den delete bitte einfach in den Destructor.

dein delete m_logger bringt das programm zum abstürzen. und wenn dann müsste dieser aufruf im destruktur sein. OnClose wird nur aufgerufen wenn man es über den Menüpunkt beendet. Ein Alt + F4 ruft diese Methode nicht auf..

habs schon gesehen - ist praktisch! hab auch schon etwas aus einem convert.xml gezogen..

1. ich bin für spaces da man so weniger probleme hat falls man es schnell in einem editor anschaut mit einer anderen tab einstellung

2. hab das wildfire doc mal überflogen. das hier find ich aber eher unschön und auch ungewohnt:


3. wo die klammer ist, ist mir eigentlich egal. nur in dieser situation finde ich es schöner auf einer neuen zeile:


oder ist dieser konstruktur eh schon nicht style konform?

4. und wo wählt man diese dpi werte aus? drei verschiedene convert eintragen finde ich unschön da man dann ziemlich schnell ziemlich viele converts hat..

5. bevor wir aber noch viel entwickeln sollten wir wohl man alles etwas umstrukturieren. und ev. auf svn umstellen? siehe http://codeforum.ch/index.php?topic=2273.0

src Ordner für programmcode
lib Ordner für unsere libs falls wir die mitlieferen wollen (tinyxml)
images Ordner für icons und bilder

wohin mit den rc files?
sprachfiles alle in einen ordner oder so lassen?

hmm.. ich glaub wir haben ein memory leak. immer wenn ich das proggi beende bekomme ich eine unschöne meldung "pdf2any.exe has encountered aproblem and needs to close.."

aber nur wenn ich über das Menü File - Exit beende!

Ich habe gestern schon etwas eingebaut in Basic.cpp. Mach am besten mal einen CVS update. Und zwar habe ich ein Log Window eingebaut, den du mit F1 anzeigen lassen kannst. Dort kannst du Traces oder Logs oder sonstige Debug Meldungen ausgeben lassen mit wxLogMessage(). Die 6 Files für das TinyXML habe ich auch schon eingecheckt (habs einfach mal im ordner "helper" abgelegt. Im Code wird das TinyXML auch schon genutzt um Daten aus dem converter.xml auszulesen und im Log Window anzuzeigen.
Du musst in dein MingWStudio Projekt Settings den include Pfad "helper/tinyxml" hinzufügen, sonst findet er "tinyxml.h" nicht.

Au??erdem müssen wir uns auf einen halbwegs gemeinsamen Coding style einigen. Z.b. sollte wir festlegen, ob wir nur Spaces zum einrücken verwenden oder Tabstopps. Momentan ist das überall im Code bunt gemixt. Mit Spaces (4Stück) stellt man halt sicher, dass es wirklich in jedem Editor gleich eingerückt ist. Was ziehst du vor ?

Hier ist z.b. mal ein Coding Style:
http://www.chris-lott.org/resources/cstyle/Wildfire-C++Style.html

Bei den geschweiften Block-Klammern bevorzuge ich leider die kompakte Schreibweise (mit der geöffneten Klammer am ende der Zeile). Du nimmst die andere Schreibweise. Ich kann mich da aber umstellen. Oder wir ignorieren das einfach und jeder macht das mit dem Klammer wir er es mag.

Wegen den DPI Angaben:
Ich finde eigentlich eine 300x300 Angabe unsinnig. Eigentlich sollte wir schon die Proportionen beibehalten, also 1 DPI Angabe und die in X und Y Richtung. Machen wir es doch so wie in dem pdf2any screenshot. Standardwerte anzeigen, z.b. 72, 100, 150, 300.

Das mit dem wx.manifest probier ich gleich mal aus. Wenn das reicht, wäre das ja super.

wegen windows xp themes. ich hab mal in den wx headers etwas gesucht und das hier gefunden:


genügt das nicht?



convert.xml - ich denke wir müssen uns hier einigen was wir alles eintragen. ev. ist es zB nicht sinnvoll die Auflösung fix auf 300x300 dpi festzulegen..



werde versuchen heute noch das config.xml zu implementieren (fenster position und grösse als erstes)

Ich denke auch, wir werden mit TinyXML zufrieden sein.
Lass uns zwei getrennte Files anlegen. Eins für die Einstellungen der Applikation selber (config.xml) und eines für die Konverter Sachen (converter.xml)

Hast du im CVS schon gesehen, dass ich 3 neue Files eigecheckt habe:
pdf2any_private.rc, pdf2any_private.h und pdf2any.Manifest

Diese Files hat mir der Dev-C++ generiert, als ich den "Windows XP Theme Support" aktiviert habe. Die Applikation sieht dann unter Windows XP noch schicker aus, weil es den Luna Look&Feel von XP nutzt. Frag mich jetzt nicht, was das "_private" bedeutet, aber das kann man auch später mal weglassen und einfach nur pdf2any.rc/.h schreiben.

Ich weiss jetzt aber nicht, wie du das beim MingWStudio Projekt file einbauen musst. Ich hab nur im Makefile gesehen, dass man mit windres.exe erstmal das pdf2any_private.res erzeugt und dieses dann einfach mit linkt. Auszug aus dem Makefile:

wx & STL geht schon aber das wird eben nicht empfohlen.. man hat dann ja auch alles doppelt (hash, string etc.)

okay dann würd ich sagen machen wir das mal mit TinyXML.

Wollen wir alles in ein File speichern? Oder Einstellungen wie Fensterposition, Sprache in ein File und Einstellungen zu den Konverter Tools in ein eigenes Files?

In den Sourcen von wx habe ich auch ein paar STL defines gesehen, also scheint es als könne man auch STL nutzen, wenn man will. Aber ich würde auch sagen, dass wir es mal ohne STL probieren. Die Konvertierung von char* nach wxString() oder umgekehrt ist kein Problem. Schau mal in die wx include in string.h und wxchar.h
Die wxString bietet einen Konstruktor an, also wxString(wxChar*);
wxChar ist ein ein typedef auf char (siehe wxchar.h)
Und andersrum bekommst du aus dem wxString object mit wc_str() den wxChr* (bzw. char*) wieder zurück.

Die Klasse wxXmlDocument() gibts ab 2.5. Man kann sie auch nutzen mit #include 'wx/xml/xml.h'.

1. ja auf jeden fall aufräumen! wie gesagt war mein testprojekt. hauptdatei sollte wohl auch nicht basic heissen..

2. wxConfig sieht je nach Umgebung anders aus. Auf Windows wird die Registry verwendet! Aber auf allen Platformen gibts eine Text File Implementierung (wxTextConfig?)

Nach Möglichkeit würde ich einfach gerne ein System für alle Konfigurationen verwenden. Dazu muss es aber genug können und sollte auch für einfache Sachen nicht zu viel Overhead generieren!

3. TinyXML sieht hübsch aus. Unsicher bin ich nur wegen der Einbindung. STL sollte man ja mit wxWidgets nicht verwenden.. TinyXML kann man mit STL kompilieren so dass dann std::string verwendet wird.. Ist aber doof dann hätten wir zwei String Klassen. Kompilieren wir es ohne STL dann müssen wir uns überlegen wie wir die Parameter konvertieren (char * zu wxString etc.) Insofern wäre mir eine wx Klasse schon lieber!

Du sprichst von einer XML Implementierung in wxWidgets 2.5 - aktuell ist inzwischen 2.6.. Vielleicht siehts da anders aus! Werd ich später mal anschauen..


ich bin bald schon weg und komme erst Samstag Abend oder sogar Sonntag zurück. Werde heute und morgen also nichts aufräumen oder weiterentwickeln..

Files im CVS umbenennen ist anscheinend nicht so toll. Einige sagen, man sollte das alte löschen und das neue Element anlegen. Dann ist halt die Historie weg. Es gibt aber auch einen Trick, mit dem man die History beibehalten kann, aber das hat dann wieder andere Nachteile und soll nicht so sicher sein:
http://www.cvsnt.org/manual/html/Moving-files.html

Vielleicht sollte wir uns über die Ordner-struktur auch schon Gedanken machen. Jetzt haben wir ja alles in einem Hauptordner. Wäre es nicht sinnvoll, wenn wir z.b. einen Ordner "images" für alle Bildchen, Icons, Texturen, .. haben, einen "src" für die .cpp/.c Files und einen "include" Ordner für die .hpp, .h Files ? Jetzt ist die Historie der Files noch klein, so dass man einen Umzug ohne Historie verkraften kann, aber später ?

Ich habe mir wxConfig mal kurz angeschaut. Ist eigentlich ganz nett, aber wenns komplexere Strukturen werden (z.b. Gruppen und Untergruppen) wird komplizierter. Wie sieht das Config File eigentlich aus ? Kann man das leicht von Hand bearbeiten wie z.b XML oder müssen wir dann einen eigenen Config-Dialog basteln um das Config File zu verwalten ?
So einfach Werte wie "letzte Fenstergrösse" oder "letzte Sprache" und so sachen die der User default mässig einstellen will, kann man sicherlich mit diesem wxConfig super bequem abspeichern. Dafür würde ich das auch nutzen.

Ab wxWidgets 2.5 gibt es eine Komponente wxXml (Klasse heisst z.b. wxXmlDocument). Aber in der Doku wird von der Klasse abgeraten, weil sich die API in der Zukunft noch ändern wird. Es sollen in den nächsten wxWidgets Releases einer neuer besser XML-Parser/Builder eingebaut werden. Aber das kan vielleicht noch dauern.

Wie wärs mit TinyXML ?
http://www.grinninglizard.com/tinyxml/index.html
Das hat genau 6 Source/Header Files im cvs und bietet eigentlich ne recht simple Parse/Write XML API:
http://cvs.sourceforge.net/viewcvs.py/tinyxml/tinyxml/
Die 6 Files könnten wir ja bei uns in einen "helper/tinyxml" Order stecken.
Hier steht sogar das man dass darf und es auch so vorgesehen ist (ca 6. Absatz):
http://cvs.sourceforge.net/viewcvs.py/tinyxml/tinyxml/readme.txt?view=markup

Mario hast du mal wxConfig angeschaut? Ist ein Wrapper der sehr einfach zu handeln ist.

"Gruppen" werden aus meiner Sicht aber etwas spezielle dargestellt

Value --> "/program/gs/format/pdf2png/command" = "bla"


sprich man gibt die gruppe einfach beim "key" an.. wäre aber die "offizielle" wxWidget Variante um Konfigurationen zu speichern.

Würde gerne ein Format festlegen da ich zum einen gerne ein paar Werte auslagern möchte aber vorallem müssten wir mal definieren können wie das bereits diskutierte Config File für die Optionen aussehen kann/muss!

ich weiss woher die konflikte mit den sprachfiles kommen. entsteht weil alle drei ordner (de,de_DE,en_GB) im gleiche CVS Ordner (de) gespeichert werden..