Magazin als Buch oder Broschüre
-
Es gibt eine Portalseite? Gibt's irgendwo Infos dazu? Hab das garnicht mitgekriegt.
-
Hallo,
Dito. Ich wusste nichts davon. Oder war die von SideWinder ein Layout dafür?
MFG winexec*
-
-
Tut sich da noch was? Der Thread ist ja auch schon älter.
-
Hallo,
Wie ich bemerke, war das joomoo und nicht SideWinder. Ich bitte um Verzeihung :D.
MFG winexec*
-
Jester schrieb:
Tut sich da noch was? Der Thread ist ja auch schon älter.
Ja, joomoo ist dabei das aufzuziehen. Bin über den aktuellen Stand aber nicht informiert. Der Deal ist, dass er mich anhaut, wenn er was braucht. Marc++us stellt uns da ja recht umfangreiche Möglichkeiten bzgl. Datenexport zur Verfügung, daher ist es wirklich sinnvoll, erst mal zu sehen, was wir damit schon alles machen können.
Artchi schrieb:
Ich bin ebenfalls dafür das wir kein CUJ-Nachfolger machen wollen. Trotzdem sollte das Print-Mag einen gewissen Magazin-Stil haben. Zwei oder drei Spalten wären gut und die Listings und Screenshots natürlich nicht in eine Spalte.
Die Frage ist für mich, ob sich dadurch irgendwas verbessert (außer dass das Layout eher Magzin-like ist) bzw. ob sich der Aufwand lohnt?
Hier die url: http://magazin.c-plusplus.info/
-
GPC schrieb:
Die Frage ist für mich, ob sich dadurch irgendwas verbessert (außer dass das Layout eher Magzin-like ist) bzw. ob sich der Aufwand lohnt?
Der Trick ist ja gerade, den Aufwand durch weitgehende Automatisierung klein zu halten.
Wie sehen denn die Export-Möglichkeiten im Portal aus?
-
Jester schrieb:
GPC schrieb:
Die Frage ist für mich, ob sich dadurch irgendwas verbessert (außer dass das Layout eher Magzin-like ist) bzw. ob sich der Aufwand lohnt?
Der Trick ist ja gerade, den Aufwand durch weitgehende Automatisierung klein zu halten.
hehe, ja, schon klar. Nur könnte ich mir vorstellen, dass ein zweispaltiges Layout mehr Aufwand macht, als ein einspaltiges?!
Wie sehen denn die Export-Möglichkeiten im Portal aus?
Mir ist nur die Möglichkeit des XML-Exports bekannt. Man kann sowohl ein komplettes Board als auch einen Thread (inkl. Antworten) per XML relativ easy rausfischen. IIRC hatte Marc++us noch mehr in petto, aber ich weiß es nicht mehr genau.
-
Das Problem ist, das es an Formatierungsmöglichkeiten fehlt. Selbst für Überschriften haben wir ja keine Möglichkeit. Daher muss man improvisieren, was dann nicht immer einheitlich ist. Daher kann man kaum automatisiert in PDF umwandeln.
-
GPC schrieb:
hehe, ja, schon klar. Nur könnte ich mir vorstellen, dass ein zweispaltiges Layout mehr Aufwand macht, als ein einspaltiges?!
Ich habe testweise im document-tag mal ein twocolumn eingefügt. Danach war alles zweispaltig. Mit multicols kann ich auch die Anzahl der Spalten angeben. Wenn die Seite nur halbvoll ist werden dann sogar automatisch alle Spalten gleichmäßig gefüllt.
Einzig die Plazierung von Bildern macht ein paar Probleme. Insbesondere Sachen wie "Hier mal etwas Code: " funktioniert natürlich nicht mehr so gut. Wenn man sich aber angewöhnen würde: "Der Code in Listing xy zeigt ..." und dann das Listing von Latex plazieren läßt, sollte es besser klappen.
-
Jester schrieb:
Wie sehen denn die Export-Möglichkeiten im Portal aus?
Thread und Forum als XML, inklusive der Verwaltungsdaten, Code ist bereits Syncol formatiert.
Habe deswegen erst vor 2 Wochen eine Email mit dem Bearbeiter (wie war der Name noch mal - habe mein Archiv gerade nicht da) ausgetauscht.
-
[quote="rüdiger"]Das Problem ist, das es an Formatierungsmöglichkeiten fehlt.
Selbst für Überschriften haben wir ja keine Möglichkeit.[quote]Das ist imho ein eher triviales Problem, da einfache Formatierungscodetags leicht erstellbar sind.
Man muss diese nicht mal mit anderen Schriftarten versehen, die werden z.B. nach wie vor mit bold ausgezeichnet, aber fuer Export kann man damit mehr machen.
Einfach [h1], [h2], [h3], die entsprechend nach HTML umgesetzt werden - fertig. Fuer Inline-Code ebenfalls einen eigenen Tag, damit unterscheidet er sich automatisch von [cpp].
-
Marc++us schrieb:
Jester schrieb:
Wie sehen denn die Export-Möglichkeiten im Portal aus?
Thread und Forum als XML, inklusive der Verwaltungsdaten, Code ist bereits Syncol formatiert
Wenn ich das richtig sehe dann sind beide Ansätze auf unterschiedlicher Ebene. Ich habe mir angeschaut, wie man mit möglichst wenig Aufwand ein sinnvolles Layout hinkriegt.
Im Portal könnt ihr die Daten strukturiert zur Verfügung stellen. Sowas wie PDF generieren wird dort aber wohl vermutlich nicht möglich sein.
Klingt als würden sich die Ansätze gut ergänzen: Durch den strukturierten Export kann man nötige Änderungen (wie zum Beispiel Überschriften) leicht durch ne Transformation vornehmen. Für's Layout etc. wäre dann das Latex-Skript da.
-
Ich hab mich jetzt nochmal umgeschaut. Das Positionieren von Objekten in mehrspaltigen Texten ist leider nicht so einfach.
Positionierungen dieser Art:
text text text text text text text te xt text text te xt text text te Bild xt text text te xt text text te xt text text text text text text textLassen sich quasi nur mit Handarbeit erreichen. Da müßten wir also ne einfachere Regelung finden wie und wo Objekte positioniert werden.
-
Ja, das sind schon richtige DTP-Features, keine Frage!
Scribus kann das.Aber es würde sowas voll ausreichen:
Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Bild Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text TextOder im noch einfachechen Fall:
Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Bild Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text Text(Bild kann natürlich auch ein Listing sein.)
Wären diese Varianten einfach möglich?
Das der Text elegant drum herum geht (in Form einer Kurve) ist nicht unbedingt wichtig.
-
Artchi schrieb:
Ja, das sind schon richtige DTP-Features, keine Frage!
Scribus kann das.LaTeX ist ja auch kein DTP-Programm. Aber dafür ist es einfach automatisierbar.
Aber es würde sowas voll ausreichen:
SNIP
Wären diese Varianten einfach möglich?
Variante 1 ist einfach möglich. Sofern das Objekt so schmal ist, daß noch Platz ist kann man sogar den Text einfach außenrum fließen lassen.
Wie soll Variante 2 aussehen? Der Text geht in den Spalten senkrecht nach dem Bild weiter? Oder wenn man beim Bild ankommt liest man in der nächsten Spalte weiter?
-
Marc++us schrieb:
Einfach [h1], [h2], [h3], die entsprechend nach HTML umgesetzt werden - fertig. Fuer Inline-Code ebenfalls einen eigenen Tag, damit unterscheidet er sich automatisch von.
Dadrauf sollten wir bei Gelegenheit mal zurückkommen.
Überschriftentags, dass wir da nie dran gedacht haben...
-
Variante 1 ist einfach möglich. Sofern das Objekt so schmal ist, daß noch Platz ist kann man sogar den Text einfach außenrum fließen lassen.
Viele Grafiken in den bisherigen Artikeln sind meistens kleine Dialog-Screenshots. Die würde man also auch erkennen können, wenn sie in eine Spalte gequätscht würden.
Wie soll Variante 2 aussehen? Der Text geht in den Spalten senkrecht nach dem Bild weiter? Oder wenn man beim Bild ankommt liest man in der nächsten Spalte weiter?
Ersteres. Wenn das Bild kommt, lese ich unter dem Bild in der selben Spalte weiter. Naja, so hab ich mir das gedacht, falls Variante 1 schwierig sein sollte umzusetzen.
Variante 2 ist übrigens für Listings nicht schlecht, da diese ja doch schon breiter ausfallen. Und dann könnte man immer im Text schreiben "Siehe Listing 2".
-
Also wie gesagt, Variante 1 geht. Variante 2, so wie Du sie willst macht ein paar Probleme. Wenn wir allerdings damit leben können, daß Latex das Bild unter Umständen ans Seitenende schiebt, oder zum Anfang der nächsten Seite, dann sollte das gehen. Dadurch, daß man eh auf das Listing referenziert und es ne Nummer kriegt sollte das ja kein Problem sein.