Software-Idee, kann aber nicht (genug) programmieren.

Gut, bleibt die Frage, wenn das Logo bei der angedachten Größe gerastert gut aussieht, warum man es unbedingt als Vektor machen sollte?
Weile kleiner ist?!? Weile besser aussieht?

Gerade wenn es für die Bildschirmdarstellung gedacht ist? Speicher das Logo doch einfach in den gängigen Größen ab, dann haben die ein paar kB und sag den Leuten, dass sie nicht die x MP-Vorlage mehr verwenden sollen.
Ich will es nicht in verschiedenen Größen abspeichern. Ich will ein Logo haben und das will ich überall verwenden.

Außerdem entwerfe ich normalerweise den ganzen Briefkopf in Illustrator und speichere ihn als PDF. Dann können die Kunden diesen auf ihr Papier drucken, in Programmen hinterlegen (wenn die Programme PDF verarbeiten können wie z.B. GrandTotal), sie können sich auch Briefpapier davon drucken lassen usw. Nur wenn man so einen Briefkopf hinterlegt, dann ist die Zeile mit den Kontodaten, Telefonnummer usw. so pixelig, dass man sie nicht mehr lesen kann. Oder man macht sie in 150 dpi, dann hat das zu versendende Dokument auch eine Größe 10 MByte.

Und die Technologie ist ja da, alle Mac-User haben sie sogar bereits auf ihrem Computer. Warum soll ich also darauf verzichten, nur weil einige merkwürdige Zeitgenossen meinen, dass verpixelte und unscharfe Logos besser sind als randscharfe Vektorlogos? Es tut mir Leid, dafür habe ich kein Verständnis.
 
Zunächst mal: Schade, dass auch ich dir konkret nicht helfen kann.
(Und dass es sonst bisher auch keiner will oder kann)

Dann frage ich mich: Du sprichst von vielen Kunden. Da davon ja etliche
keinen Mac haben werden, wäre das keine Komplettlösung. Sondern nur
für Apple User?

Und zum Thema Größe (das Zitat)
Oder man macht sie in 150 dpi, dann hat das zu versendende Dokument auch eine Größe 10 MByte.

Durch JPG-Kompression, auch in TIFFs, wird die Größe wesentlich kleiner. Im Vergleich
zu deiner Angabe um den Faktor 1:20 !!
Normale Logos mit 300 ppi haben max. 100 kb. Komplette Briefköpfe in 300 ppi,
wo auch kleine Schriften scharf sind, haben max. 500 kb, wenn viel weißes Papier
im Spiel ist, sogar nur 250 k oder weniger.

Komplette A4-Seiten in 300 ppi (nur Text und Logo, viel Weiß) haben nur 250 kb

Probiers aus. Speichere in Photoshop "für Web speichern" (vermeidet unnötige Daten)
und vergleiche verschiedene Kompressionsstufen. Du wirst überrascht sein.

Oft braucht ein Bild im PDF weniger Speicher als eingebundene Schriften oder Vektoren.
 
Also Leute, ohne mich an der Diskussion im Kern beteiligen zu wollen, aber...

eigentlich wird hier nur nach jemandem gefragt, der eine App programmieren und sich ein paar Cent verdienen möchte. Das ist durchaus in Ordnung und ein nettes Angebot.
Was der Inhalt der Programmierung ist, spielt (solange sie rechtlich einwandfrei ist) keine Rolle oder? Ich kann leider (noch) nicht so programmieren, dass es für gewerblichen Nutzen reichen würde, sonst hätte ich das gemacht. Mir doch egal ob es dafür einen Abnehmer gibt, solange ich keine Kosten für den Aufwand habe und mir damit ein paar Euro in die Kasse gespült werden.

Also lasst doch die Grundsatzdiskussionen um Sinn und Unsinn von PDF Implementierung in andere Dokumente einfach sein (das ist ja nicht Topic) und derjenige, der das progammieren kann und will soll sich melden.
Dann ist doch alles gut.

:noplan::zeitung:
 
  • Gefällt mir
Reaktionen: smn, magicmann, cropfaktor und eine weitere Person
Dann frage ich mich: Du sprichst von vielen Kunden. Da davon ja etliche
keinen Mac haben werden, wäre das keine Komplettlösung. Sondern nur
für Apple User?
Ja, denn Windows hat leider keine PDF-API.

Oft braucht ein Bild im PDF weniger Speicher als eingebundene Schriften oder Vektoren.
Das ist mir natürlich bekannt, denn ich bin ein Druckvorstufen-Fachmann. ;-) Daher binde ich in diesem Fall auch nur die tatsächlich verwendeten Zeichen einer Schrift ein (Untergruppen) und nicht die ganze Schrift. Manche Schriften haben tausende von Zeichen und sind manchmal dutzende von MByte groß. AdobeSongStd-Light-Acro.otf z.B. hat bei mir schon 15 MByte, und ist sicher nicht die größte Schrift.
 
...nun hab ich die 7 Seiten eurer Diskussion durchgelesen und weise einfach mal auf den Eingangspost des TE hin. Ich frage mal: Kann das einer von euch programmieren, so wie es sich der TE vorstellt? Ja oder nein? Unabhängig davon, ob er es gut findet, er -zig Alternativlösungen kennt oder sonstwas??
 
  • Gefällt mir
Reaktionen: smn, MAC.BS1971 und uhlhorn
...nun hab ich die 7 Seiten eurer Diskussion durchgelesen und weise einfach mal auf den Eingangspost des TE hin. Ich frage mal: Kann das einer von euch programmieren, so wie es sich der TE vorstellt? Ja oder nein? Unabhängig davon, ob er es gut findet, er -zig Alternativlösungen kennt oder sonstwas??
Da gäbe es bestimmt jemand - alles was man nicht Löten kann muss man eben Programmieren.
Die Frage ist nur, ob sich jemand findet, der in etwas Zeit und somit auch Geld investiert, was offensichtlich nur sehr wenige benötigen würden...

@@ schau.hans: Danke für das Beispiel, aber das kann ich meinen Kunden nicht zumuten. Die haben sich einen mac gekauft WEIL es dort einfacher sein soll.
Jaja, das ist oft das Problem. Mit einem Mac is eben alles einfacher.

...zumindest in der Theorie...

In der Praxis jedoch gibt es einige Dinge, die unter Windows halt doch einfacher sind. Selbst kleine Faktura-Programme wie Lexware (...gibts auf als Netzwerkversionen...) können Problemlos saubere .pdfs in Rechnungen einbauen.

Aber, jetzt mal was ganz anderes: Vielleicht wäre Deinen Kunden damit geholfen, wenn sie ihre Prozesse generell optimieren, bzw. auf den Prüfstand stellen?
Ich mache hier auch viel mit Online Rechnungen und hab deswegen mein Rechnungslayout auf ausschliesslich Text umgestellt.

Is doch wurscht, wie die Rechnung aussieht, Hauptsache sie ist gesetzeskonform und wird bezahlt ;)

Charlie
 
Ich frage mal: Kann das einer von euch programmieren, so wie es sich der TE vorstellt?

Das ist, glaube ich, nicht das Problem. Soll heißen, hier gibt es sicher genug fähige Programmierer, die das programmieren könnten. Nur sieht man an diesem Thread ja sehr schön, dass kaum jemand von der Idee oder dem Nutzen überzeugt ist. Und ein Programmierer wird wohl kaum bereit sein kostbare Freizeit in das Projekt zu investieren, wenn er nicht davon überzeugt ist, dass sich die App später auch verkauft (er soll ja schließlich durch den Verkauf entlohnt werden). Ich kann daher die geringe positive Resonanz durchaus verstehen, schließlich liefert der Threadersteller nur eine Idee, der Programmierer hat aber die Arbeit und das Risiko, dass sich die App nicht verkauft. Ist die Idee dann nicht überzeugend, ist die Bereitschaft entsprechend gering.
Eine Alternative wurde ja schon vorgeschlagen: Wenn der Threadersteller meint, dass diese App so viele Abnehmer finden würde, soll er doch einen Programmierer mit der Programmierung beauftragen, bezahlen (der Arbeitsaufwand sollte sich in Grenzen halten) und die App dann selbst einstellen. Dann hat der Programmierer wenigstens eine finanzielle Sicherheit. Aber das hat der Threadersteller ja schon abgelehnt (so überzeugt scheint also auch er nicht zu sein).

Aber ein konstruktiver Beitrag noch von mir: Die Lösung mit PDFTK finde ich eigentlich sehr interessant. Denn PDFTK läuft auf allen Plattformen (Mac OS X, Linux, Windows). Ein Shell-Skript, das die Verwendung etwas vereinfacht (wenn der Benutzer kein Terminal verwenden will), ist schnell geschrieben und schon kann man die wichtigsten Sachen damit erledigen. Gut, ist nicht ganz so intuitiv wie eine GUI und der Anwender braucht eine kurze Einweisung, was er wie machen muss, aber dafür braucht die Lösung wenig Zeit und wenn der Anwender das regelmäßig verwendet, wird er auch mit dem Ablauf zurecht kommen.
 
Ich versteh' den Sinn immer noch nicht... Einfach Layout im Rechnungsprogramm, Grafik einbinden, fertig. Warum ein PDF als Hintergrund? Warum nicht TIFF oder JPG??? Es muss kein Programm geschrieben werden, um irgendetwas "geradezubiegen" - die Hersteller der Rechnungsprogramme müssen ihre Programme ordentlich gestalten, so dass Layouts möglich sind... :noplan:
 
Ich versteh' den Sinn immer noch nicht... Einfach Layout im Rechnungsprogramm, Grafik einbinden, fertig. Warum ein PDF als Hintergrund? Warum nicht TIFF oder JPG??? Es muss kein Programm geschrieben werden, um irgendetwas "geradezubiegen" - die Hersteller der Rechnungsprogramme müssen ihre Programme ordentlich gestalten, so dass Layouts möglich sind...

Ich vermute mal, würde es ein Rechnungsprogramm geben, das die Funktionalität bietet, die der Threadersteller haben möchte, würde er hier nicht fragen. Warum er ein pdf benutzen möchte und kein TIFF/JPG? Weil der Threadersteller gerne eine Vektorgraphik als Hintergrund einfügen will und er somit ein Datei-Format verwenden muss, das auch Vektorgraphiken beinhalten kann. Zum Rest: Siehe es mal so. Wenn der Entwickler einer Software wirklich alle Anwenderwünsche in sein Programm einbauen würde, würde das Programm nach einer gewissen Entwicklungszeit vermutlich auf Grund der vielen Zusatzfunktionen an Peformance, Sicherheit und Übersicht/Benutzbarkeit verlieren. Der Entwickler muss also einen Kompromiss finden zwischen all diesen (und sicher noch mehr) Faktoren, sodass er am Ende nur einen bestimmten Funktionsumfang (der wichtigsten/nachgefragtesten Funktionen) implementieren wird. Daher ist es durchaus legitim nach einem (Zusatz-)Programm zu fragen, das eine fehlende Funktion übernimmt.

Fragt sich nur, ob es dafür extra ein komplett neues Programm sein muss, dessen GUI auf wenige Funktionen zugeschnitten ist und dadurch sehr leicht ("idiotensicher") in der Anwendung ist. Oder ob man nicht bestehende Programme geringfügig abwandelt/erweitert und das dann als Lösung verwendet, auch wenn die Bedienung dann etwas komplexer wird.
 
Is doch wurscht, wie die Rechnung aussieht, Hauptsache sie ist gesetzeskonform und wird bezahlt ;)
Hey, sag mal, was ist denn das bitte für eine Einstellung?!? Machst Du Deine Arbeit etwa auch so?

Und Lexware ist eine ganz große Katastrophe! Bei fast jedem Update gibt es Probleme. Einmal sogar wurden die Buchungen der verschiedenen Mandanten durcheinander gebracht. Nein, Lexware geht gar nicht! Wir (unsere Firmen) sind inzwischen auch weg davon, bis auf eine unserer Firmen, die das noch haben muss.
 
Und ein Programmierer wird wohl kaum bereit sein kostbare Freizeit in das Projekt zu investieren, wenn er nicht davon überzeugt ist, dass sich die App später auch verkauft (er soll ja schließlich durch den Verkauf entlohnt werden).
Ja, was ich ja auch verstehe. Allerdings wollte ich das Thema eigentlich nicht diskutieren. Ein einfaches „Nein“ hätte es auch getan.

Eine Alternative wurde ja schon vorgeschlagen: Wenn der Threadersteller meint, dass diese App so viele Abnehmer finden würde, soll er doch einen Programmierer mit der Programmierung beauftragen, bezahlen (der Arbeitsaufwand sollte sich in Grenzen halten) und die App dann selbst einstellen. Dann hat der Programmierer wenigstens eine finanzielle Sicherheit. Aber das hat der Threadersteller ja schon abgelehnt (so überzeugt scheint also auch er nicht zu sein).
Das habe ich nicht aus Mangel an Überzeugung abgelehnt, sondern aus anderen Gründen. Stellt sich jetzt nämlich heraus, dass es doch eine erfolgreiche Software ist, dann macht mir der Entwickler Konkurrenz indem er selbst so eine App einstellt (entwickeln muss er sie dann ja nicht mehr) und arbeitet an mein Programm nicht mehr richtig weiter. Zumindest steht er in diesem Konflikt. Und DAS Risiko will ich nicht eingehen. Würde ich selbst nicht an die Idee glauben, hätte ich kein Problem jemanden zu beauftragen. Doch ich mache es eben nicht, WEIL ich daran glaube. ;-)

Nebenbei:
Dieser Thread hat dafür gesorgt, dass ich viele E-Mails bekommen habe. Die meisten haben gesagt, dass es vergebene Mühe ist hier zu diskutieren. Einige haben auch Interesse an so einem Programm äußert und ich solle die Idee doch wo anders anbieten. Zumindest wollten sie bis dahin meine AppleScript-Lösung gerne haben. Ich werde sie noch mal etwas polieren und dann anbieten.

Aber ein konstruktiver Beitrag noch von mir: Die Lösung mit PDFTK finde ich eigentlich sehr interessant. Denn PDFTK läuft auf allen Plattformen (Mac OS X, Linux, Windows). Ein Shell-Skript, das die Verwendung etwas vereinfacht (wenn der Benutzer kein Terminal verwenden will), ist schnell geschrieben und schon kann man die wichtigsten Sachen damit erledigen. Gut, ist nicht ganz so intuitiv wie eine GUI und der Anwender braucht eine kurze Einweisung, was er wie machen muss, aber dafür braucht die Lösung wenig Zeit und wenn der Anwender das regelmäßig verwendet, wird er auch mit dem Ablauf zurecht kommen.
Das kann man für Windows so machen, für Linux sowieso. Für den Mac ist das indiskutabel. SOWAS wird tatsächlich kaum Abnehmer finden.

Es wird ja oft gefragt, warum Apple so erfolgreich ist, und andere Firmen nicht. Hier hast Du die Antwort. Genau so wie Du machen es die anderen Firmen. Sie machen unnötige Kompromisse und damit nur mäßig gute bis schlechte Produkte. Oder eine Einstellung wie CharlieD, der meint, dass es egal ist wie eine Rechnung aussieht.

Eine Sekretärin hat keine Lust bei jedem Angebot das Terminal zu bemühen. Damit wäre sie auch überfordert, denn sie weiß ja nicht mal was ein Terminal ist und wozu man es verwenden kann. Ihr müsst Euch in die Kunden hineindenken, und nicht Eure eigene Sicht auf die Dinge verallgemeinern, und annehmen, dass andere das auch so sehen.
 
Einfach Layout im Rechnungsprogramm, Grafik einbinden, fertig. Warum ein PDF als Hintergrund? Warum nicht TIFF oder JPG???
Weil Schrift als TIFF oder JPG einfach grauenhaft aussieht.

Ich habe hier einen kompletten Briefkopf, oben Logo, Adressfeld mit Absender, unten Zeile mit Adresse, Telefonnummer, E-Mail-Adresse, Bankverbindung, Steuernummer usw. Links habe ich Loch- und Pfalzmarken. Bei Mac-Programmen wie Grand Total kann man jetzt einfach den ganzen Briefkopf hinterlegen, und alle Schriften, Logos usw. bleibt wie im ursprünglichen PDF eben Schriften und Vektoren. Bei Topix und Monkey Office hingegen wird es in Pixel umgewandelt mit 75 dpi. Die Adresszeile ist nicht mehr zu lesen. Das Logo sieht aus wie ausgekotzt. Die Seitenränder in Monkey Office verschieben den hinterlegten Brief an eine Position wo er nicht stehen soll. Es sieht alles hässlich und unscharf aus.

Gut, man kann jetzt die Auflösung erhöhen. Damit sieht es dann etwas besser aus. Aber die Dateigröße steigt auch erheblich an. Jetzt kann man die Kompression des JPGs erhöhen, alles bekommt hässliche Kompressionsartefakte. Man kann es drehen und wenden wie man will, es sieht immer beschissen aus oder wies viel zu groß :-(

Dabei haben wir eine technische Lösung dafür: PDF. Das Problem daran ist nur, dass Windows keinerlei PDF-APIs hat, und daher alle Programme, die systemübergreifend geschrieben werden, leider auf PDF-Support verzichten müssen. Und dort liegt das Problem.
 
Wenn der Entwickler einer Software wirklich alle Anwenderwünsche in sein Programm einbauen würde, würde das Programm nach einer gewissen Entwicklungszeit vermutlich auf Grund der vielen Zusatzfunktionen an Peformance, Sicherheit und Übersicht/Benutzbarkeit verlieren.
Ja, das auch. Aber das ist nicht das Problem. Der Hintergrund ist folgender: Wenn ein Entwickler ein reines Mac-Programm entwickelt, dann erbt dieses Programm die PDF-Funktionalität vom Betriebsystem. Das ist in der API bereits enthalten. Der Entwickler muss für PDF keine einzige Zeile extra Code schreiben.

Schreibt er sein Programm aber auch für Windows, kann er die Apple-APIs nicht verwenden, denn es gibt sie ja unter Windows nicht. Nun müsste er also den PDF-Support selbst schreiben, und das ist so umfangreich, dass der Entwicklungsaufwand alleine für den PDF-Support höher wäre als für das eigentliche Programm. Und das macht verständlicherweise keiner – nicht mal der Riese Topix. Und das kann ich durchaus nachvollziehen. Und DAS lohnt sich dann auch tatsächlich nicht.
 
Ihr müsst Euch in die Kunden hineindenken, und nicht Eure eigene Sicht auf die Dinge verallgemeinern, und annehmen, dass andere das auch so sehen.

Ab und zu nicht vergessen aus dem Kunden wieder rauszudenken, sonst komm sowas wie hier bei raus ;) Aus Programmierersicht: programmieren lässt sich das relativ einfach, kein großer Aufwand dahinter. Ich sehe aber auch kein wirkliches Potential dahinter. Deine Qualitätsansprüche in allen Ehren, finde ich gut, aber scheinbar wollen die Kunden das eben nicht. Vielleicht wollen es deine 3 Kunden oder du willst es für deine 3 Kunden, aber einen "Markt" dafür sehe ich nicht und daher würde ich als Programmierer, wenn ich Zeit hätte, das Projekt ablehnen.

Ich finde gut, dass du einen gewissen Qualitätsanspruch hast und nicht alles so machen willst wie die "Großen", auch wenn es eigentlich Schrott ist. Aber ich spreche aus eigener Erfahrung, am Ende zählt für den Kunden nur eins: es muss funktionieren und darf nicht die Welt kosten. Wenn ein Kunde dich fragt, warum das Logo so scheiße aussieht und ob das nicht besser geht und du ihm dann eine Lösung präsentierst, die paar tausend Euro kostet, wird der Kunde mit großer Wahrscheinlichkeit sagen "Nein danke", weil dafür lohnt es sich einfach nicht.

Die Idee mag ja ganz nett sein, aber ich sehe da eher einen speziellen Anwendungsfall und kein Angebot für die "Masse", womit man dann z.B. über den AppStore Geld verdienen könnte.

Mein Rat als Programmierer: wende dich ab von der Idee, die ist zwar ganz gut, aber nicht praxistauglich und stecke die Arbeit in diese Idee lieber in andere möglichere Lösungswege für deine Kunden. Denn denke immer dran: "Es gibt mehr als einen Weg!" ;)


Viele Grüße
Martin
 
  • Gefällt mir
Reaktionen: yofresh
Weil Schrift als TIFF oder JPG einfach grauenhaft aussieht.

Ich habe hier einen kompletten Briefkopf, oben Logo, Adressfeld mit Absender, unten Zeile mit Adresse, Telefonnummer, E-Mail-Adresse, Bankverbindung, Steuernummer usw. Links habe ich Loch- und Pfalzmarken. Bei Mac-Programmen wie Grand Total kann man jetzt einfach den ganzen Briefkopf hinterlegen, und alle Schriften, Logos usw. bleibt wie im ursprünglichen PDF eben Schriften und Vektoren. Bei Topix und Monkey Office hingegen wird es in Pixel umgewandelt mit 75 dpi. Die Adresszeile ist nicht mehr zu lesen. Das Logo sieht aus wie ausgekotzt. Die Seitenränder in Monkey Office verschieben den hinterlegten Brief an eine Position wo er nicht stehen soll. Es sieht alles hässlich und unscharf aus.

Gut, man kann jetzt die Auflösung erhöhen. Damit sieht es dann etwas besser aus. Aber die Dateigröße steigt auch erheblich an. Jetzt kann man die Kompression des JPGs erhöhen, alles bekommt hässliche Kompressionsartefakte. Man kann es drehen und wenden wie man will, es sieht immer beschissen aus oder wies viel zu groß :-(
(...)

Also ein JPG mit 350 dpi sieht nicht grauenhaft aus, sondern perfekt druckreif auch
bei sehr kleinen Schriften. Zumal sowieso „nur“ mit Home-Office Druckern gedruckt wird.

Die Größe hält sich mit etwa 300 KB auch sehr in Grenzen.

Oder gibt es bei Monkey Office das Problem, dass solch kleine JPG-Dateien beim Import
neu verarbeitet und daher sehr groß werden? Und zusätzlich sich die Qualität verschlechtert?
Das wäre dann wirklich ein Problem...
 
am Ende zählt für den Kunden nur eins: es muss funktionieren und darf nicht die Welt kosten. Wenn ein Kunde dich fragt, warum das Logo so scheiße aussieht und ob das nicht besser geht und du ihm dann eine Lösung präsentierst, die paar tausend Euro kostet, wird der Kunde mit großer Wahrscheinlichkeit sagen "Nein danke", weil dafür lohnt es sich einfach nicht.
Ja, genau. Und Du sagst auch weiter:
Aus Programmierersicht: programmieren lässt sich das relativ einfach, kein großer Aufwand dahinter.
Deswegen wollte ich es auch so machen. ;-)

Vielleicht wollen es deine 3 Kunden oder du willst es für deine 3 Kunden, …
Ich habe inzwischen mehrere E-Mails erhalten von Leuten, die sich für so ein Programm interessieren, aber keine Lust haben sich hier an der Diskussion zu beteiligen.

Und was ich will, ist nicht maßgeblich. ;-) Meine Kunden haben sich nur beschwert, dass das schlecht aussieht. Sie haben nach etwas besserem gefragt, aber nicht nach PDF. Ich habe denen erzählt, dass mit PDF eine Lösungstechnologie existiert und denen Beispiele gezeigt. Und jetzt wollen sie die Software. Doch ich kann das nicht entwickeln. Ich kann es nur als AppleScript mit irgendwelchen Open Source PDF-Tools (pdftk?). Das geht auch, doch muss ich das meinen Kunden immer installieren. Meine Kunden werden von mir auch gut betreut, aber tausende andere haben nicht die Möglichkeit. Und für die wäre eine EINFACHE Lösung ideal!

… die paar tausend Euro kostet, wird der Kunde mit großer Wahrscheinlichkeit sagen "Nein danke", weil dafür lohnt es sich einfach nicht.
Eben, deswegen suche ich ja auch nach einer einfachen Lösung! ;-) Wenn die Entwickler von Topix & Co das einbauen, müssten sie die ganze PDF-Suite selbst schreiben, denn Windows bietet keine fertige PDF-API. Und das wäre in der Tat sehr teuer und würde von niemanden bezahlt werden wollen. Aber eine kleine Drag&Drop-Lösung wäre auf dem Mac wahrscheinlich an einem Nachmittag erstellt. Und ich bin sicher, dass es viele gibt, die ihre Angebote auch als Visitenkarte betrachten und nicht akzeptieren, dass das wie gewollt, aber nicht gekonnt aussieht.

Denn denke immer dran: "Es gibt mehr als einen Weg!"
Ich denke, das weiß ich als Querdenker sicher mehr als jeder Andere! Aber ich möchte für meine Kunden die beste Lösung, nicht die naheliegendste bieten. Und außerdem ist das nicht so sehr für meine Kunden, denn für die habe ich mehrere Möglichkeiten es zu lösen. Ich sehe aber aus meiner Erfahrung heraus, dass es einen sehr großen Bedarf dafür gibt, auch in anderen Firmen. Und ich dache, dass jemand, der das kann, sich schell ein paar Euro dazuverdienen kann. Aber das scheint wohl niemanden zu reizen.

Na ja, mir ist das egal. Macht es oder lasst es sein. Nur wenn man eine schlechte Lösung – so wie hier mehrfach vorgeschlagen wurde – anbietet, dann kann man es auch gleich ganz sein lassen. Denn schlechte Lösungen haben wir bereits genug. Da gibt es wirklich keinen Bedarf mehr.

Übrigens hat Apple fast alles, für das es angeblich auch keinen Bedarf gab, so erfolgreich gemacht, wie sie jetzt sind. ;-)
 
Oder gibt es bei Monkey Office das Problem, dass solch kleine JPG-Dateien beim Import
neu verarbeitet und daher sehr groß werden? Und zusätzlich sich die Qualität verschlechtert?
Das wäre dann wirklich ein Problem...
Ja, das auch.
Aber kleine Schriften sehen auch in 300 dpi unscharf aus. Und man kann auch nicht die Kontonummer markieren und kopieren um sie in das Überweisungsformular vom Online-Banking einzusetzen. Die einzige Möglichkeit ist, das Dokument komplett mit den (Un-) Möglichkeiten des entsprechenden Programms neu aufzubauen. Aber das ist auch nur suboptimal. Es ist eben nicht die beste Lösung.
 
Ja, das auch.
Aber kleine Schriften sehen auch in 300 dpi unscharf aus. Und man kann auch nicht die Kontonummer markieren und kopieren um sie in das Überweisungsformular vom Online-Banking einzusetzen. Die einzige Möglichkeit ist, das Dokument komplett mit den (Un-) Möglichkeiten des entsprechenden Programms neu aufzubauen. Aber das ist auch nur suboptimal. Es ist eben nicht die beste Lösung.
Sieht tatsächlich so aus, als ob die Welt der professionell angebotenen Buchführungs-/Rechnungsprogramme suboptimal ist... Ich glaube, wenn ich auf so einen Schrott angewiesen wäre, würde ich mich hinsetzen und mir mit FileMaker und Layouts selber was "stricken"... :nono:
 
  • Gefällt mir
Reaktionen: yofresh
Also ich find es mehr als traurig, das der tread ersteller überhaupt um den sinn/ nutzen diskutieren muss. Das ist doch wohl sein bier, und grund frage war wohl, ob hier ein entwickler wäre der ihm helfen könnte, seine idee um zu setzen. Was daran nun so schwer? Wenn ichs könnte würd ichs machen""
 
@ Udo2009: Na ja, die Programme sind eigentlich schon gut. Gerade Monkey Office ist ansonsten allererste Sahne! Nur bei dieser Sache ist es nahezu unbrauchbar, weswegen ich es auch nur für die Buchhaltung verwende und nicht zum Rechnungschreiben. Für meine Rechnungen verwende ich GrandTotal. Auch aller erste Sahne. Aber es ist leider nicht netzwerkfähig.
 
Zurück
Oben Unten