Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 01 09:05
    pgundlach commented #336
  • Jun 01 08:31
    pgundlach closed #336
  • May 25 11:45
    pgundlach closed #335
  • May 25 11:45

    pgundlach on develop

    B: empty first page with Insert… Version 4.4.1 Start version 4.5.1 and 2 more (compare)

  • May 25 11:36

    pgundlach on 4_4_0

    B: empty first page with Insert… Version 4.4.1 (compare)

  • May 25 10:50
    pgundlach assigned #335
  • May 25 10:50
    pgundlach labeled #335
  • May 25 10:50
    pgundlach milestoned #335
  • May 25 10:50
    pgundlach opened #335
  • May 12 12:03

    pgundlach on master

    New example base64decode (compare)

  • May 12 11:55

    pgundlach on master

    MetaPost example (compare)

  • May 11 12:22

    pgundlach on develop

    Version 4.4 Update News (compare)

  • May 11 11:42
    pgundlach closed #310
  • May 11 11:42
    pgundlach commented #310
  • May 11 09:05

    pgundlach on develop

    Warn user if Windows path has n… D: Minor enhancements in docume… Version 4.3.21 (compare)

  • May 10 11:26
    pgundlach commented #310
  • May 04 17:45
    pgundlach closed #334
  • May 04 17:45

    pgundlach on develop

    Multiple NewPage should create … Version 4.3.20 (compare)

  • May 04 13:42
    pgundlach assigned #334
  • May 04 13:42
    pgundlach labeled #334
Patrick Gundlach
@pgundlach
@KKrabbes Good question. I think that does not work at the moment. You could save the base64 contents to an external file and then read the filecontents back in
@KKrabbes for example:
<Layout xmlns="urn:speedata.de:2009/publisher/en"
    xmlns:sd="urn:speedata:2009/publisher/functions/en">

    <Record element="data">
        <SetVariable variable="fn" select="sd:filecontents(sd:decode-base64(.))"></SetVariable>
        <PlaceObject>
            <Image file="{$fn}"></Image>
        </PlaceObject>
    </Record>
</Layout>
and the data file:
xml
<data>iVBORw0K...</data>
KKrabbes
@KKrabbes
Thanks for the swift answer. Unfortunately when I try this I get the following error
Searching for image "C:\\Users\\xxx\\AppData\\Local\\Temp\\OkLw7ZEkyfFrxvdA5EHB"

An error occurred: Can't determine object width
stack traceback:
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:242: in function 'assert'
        ...s (x86)\speedata-publisher\sw/lua/publisher\commands.lua:2598: in function <...s (x86)\speedata-publisher\sw/lua/publisher\commands.lua:2359>
        ...gram Files (x86)\speedata-publisher\sw/lua/publisher.lua:684: in function 'dispatch'
        ...gram Files (x86)\speedata-publisher\sw/lua/publisher.lua:1250: in function 'initialize_luatex_and_generate_pdf'
        ...gram Files (x86)\speedata-publisher\sw/lua/publisher.lua:882: in function <...gram Files (x86)\speedata-publisher\sw/lua/publisher.lua:842>
        [C]: in function 'pcall'
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:53: in function 'call'
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:394: in function 'main_loop'
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:403: in main chunk
        [C]: in function 'require'
        [\directlua]:1: in main chunkError: [page 2] ...Files (x86)\speedata-publisher\sw/lua/publisher\grid.lua:596: attempt to perform arithmetic on local 'width_sp' (a nil value)
stack traceback:
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:55: in function 'call'
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:394: in function 'main_loop'
        ...les (x86)\speedata-publisher\sw/lua/publisher\spinit.lua:403: in main chunk
        [C]: in function 'require'
        [\directlua]:1: in main chunk
Stop processing data
I tried getting the object width with {sd:imagewidth($fn)} but the error is the same. The file is working, i can open the image with paint for example. So would it help perhaps to give the file a name ending with .png or is this irrelevant?
KKrabbes
@KKrabbes
Sorry, was my bad, i had the wrong placeObject area. Now it works like a charm. Thanks alot
Patrick Gundlach
@pgundlach
@KKrabbes thank you for your feedback!
BTW: the layout above could be shortened, you don't need the <SetVariable>, you can do this all in one step (<Image file="{sd:filecontents(sd:decode...))" />)
Joerg
@jorg.l_gitlab

Hallo Patrick,
im Handbuch steht bei NewPage „.. erzeugt eine neue Seite. Diese wird nur angelegt, wenn später Text o.ä. ausgegeben wird.“
Bei mir wird jedoch, auch wenn kein Text ausgegeben wird, am Ende des Dokuments eine leere Seite angefügt.

```<Output area="textfeld">
<Text>
<Paragraph>

</Paragraph>
</Text>
</Output>

<NewPage pagetype="ersteseite" openon="right" />```

(Definiert sind Pagetype ersteseite, linkeseite und rechteseite.)
Immer wenn die Anzahl der erzeugten Seiten gerade ist, wird zusätzlich eine Seite vom Typ „ersteseite“ angefügt. Ist die Anzahl ungerade, wird eine Seite vom Typ „linkeseite“ angefügt.
Was mache ich falsch?

Patrick Gundlach
@pgundlach
Ist es möglich, mir das Layout/Daten zu schicken?
Joerg
@jorg.l_gitlab
Ja, schicke ich dir.
Joerg
@jorg.l_gitlab
https://gitlab.com/jorg.l/speedata-01
Speedata-Version ist 4.3.14
Patrick Gundlach
@pgundlach
Interesting...
Patrick Gundlach
@pgundlach
@jorg.l_gitlab Die leere Seite wird wegen openon="right" ausgegeben. Ich muss noch überlegen, ob ich das ändern kann (vermutlich schon), ohne Rückwärtskompatbilität zu gefährden.
Als Workaround kannst du vor jedem Brief Seitenumbrüche einfügen, bis die aktuelle Seitenzahl ungerade ist.
Joerg
@jorg.l_gitlab
Wenn ich openon="right" weglasse, dann wird am Schluss immer eine Seite angefügt, egal ob gerade oder ungerade.
Seitenimbrüche vor dem Brief bewirken ja dass der Brief nicht mehr mit Seite 1 beginnt. Besserer Workaround ist, die letzte Seite mit einem externen Programm (z. B. qpdf) abzuschneiden.
Patrick Gundlach
@pgundlach
Sollte nicht:
  <While test="sd:even(sd:current-page())">
    <NewPage />
  </While>
Direkt hinter <Record element="Briefe"> macht für mich genau das richtige
Und ohne openon="right" gibt es bei mir keine zusätzliche (leere) Seite
<Record element="Briefe">
  <While test="sd:even(sd:current-page())">
    <NewPage />
  </While>
  <Output area="textfeld">
    <Text>
      <Paragraph>
        <Value select="sd:dummytext(16)"/>
      </Paragraph>
    </Text>
  </Output>
</Record>
Joerg
@jorg.l_gitlab
Leider fuktioniert das so nicht. "ersteseite" ist nicht die erste Seite des Doluments sondern die erste Seite des jeweiligen Datensatzes. Füge ich nach While <NewPage pagetype="ersteseite"/> ein, dann funktioniert es nur wenn jeder Brief eine gerade Seitenanzahl hat. Bei ungerader Seitenanzahl wird "ersteseite" nur am Anfang des Dokuments verwendet, nicht am Anfang jedes neuen Briefes. Ein neuer Brief schließt sich fortlaufend an, ohne Seitenwechsel.
Patrick Gundlach
@pgundlach
@jorg.l_gitlab Dann kann man doch folgendes machen, oder?
<Record element="Briefe">
  <While test="sd:even(sd:current-page())">
    <NewPage pagetype="ersteseite" />
  </While>
  <Output area="textfeld">
    <Text>
      <Paragraph>
        <Value select="sd:dummytext(30)"/>
      </Paragraph>
    </Text>
  </Output>
  <Switch>
    <Case test="sd:odd(sd:current-page())">
      <NewPage  />
    </Case>
  </Switch>
</Record>
Joerg
@jorg.l_gitlab

Ja, das kann man machen, und es funktioniert auch. :-) Vielen Dank.
Die Funktion NewPage wird aber in Zukunft korrigiert? Denn das Handbuch sagt ja, dass leere Seiten nicht ausgegeben werden.

Wenn du dran bastelst, wäre es schön, wenn bei openon="right" ganz am Schluss der PDF noch die entsprechende leere linke Seite angefügt würde. Das ist nämlich im obigen Beispiel nicht der Fall.

Patrick Gundlach
@pgundlach
@jorg.l_gitlab das mit der leeren linken Seite verstehe ich nicht (der letzte Absatz). Hast du dafür ein Beispiel?
Für den ersten Fall habe ich #329 ersellt.
Joerg
@jorg.l_gitlab

Ich zitiere mal das Handbuch: „wenn auf Seite 1 ein Seitenwechsel erzwungen wird mit openon="right", dann wird Seite zwei leer“. In manchen Fällen (nicht immer – deshalb sollte das konfigurierbar sein), will man, dass das auch bei der letzten Seite so ist. Wenn also wie in meinem Beispiel Briefe mit Vorder- und leerer Rückseite gedruckt werden sollen, sollte wahlweise beim letzten Brief auch die leere Rückseite eingefügt werden.

Auch bei gehefteten Seiten ist das nützlich. Wird z. B. die Seitennummerierung automatisch erzeugt, sollte auf alle Seiten eine Seitenzahl gedruckt werden, auch auf die leeren. Hier evtl. sogar auf die 3 letzten Seiten, da bei zu A5 gefalteten A4-Seiten die Gesamtseitenanzahl immer durch 4 teilbar sein muss.

Patrick Gundlach
@pgundlach
@jorg.l_gitlab also syntactic sugar für
<Until test=" sd:current-page() mod 4 = 0">
    <NewPage />
</Until>
oder?
Patrick Gundlach
@pgundlach
(Das Problem mit NewPage am Ende des Dokuments ist nun behoben #329)
Joerg
@jorg.l_gitlab

Leider ist das Problem mit NewPage noch nicht ganz behoben: Endet das Dokument mit einer rechten Seite, ist alles in Ordnung, endet es mit einer linken Seite, wird auch jetzt noch eine leere Seite angefügt.

Zu der anderen Sache war meine Idee nur, dass wenn openon="right" bewirkt, dass das Teildokument immer mit einer rechten Seite beginnt, sollte es auch immer mit einer linken Seite enden. Das ist auch der Fall, nur beim letzten Teildokument nicht. Aber das kann man ja im Bedarfsfall auch mit entsprechendem Code abfangen.

Noch etwas zum Hintergrund. Bei einem Einzeldokument mit vielen Seiten kann man das alles individuell anpassen. Da ist natürlich ein „syntactic sugar“ nicht notwendig. Eine Codezeile kann man auch per Hand einfügen. Wie du in meinem Beispiel gesehen hast, erstelle ich vorrangig PDF-Dateien mit vielen Einzeldokumenten, die dann in ein Dokumentenmanagementsystem geschoben wird, das die Einzeldokumente an verschiedenen Stellen ablegt. In diesem Fall geschieht die Seitennummerierung auch nicht über sd:current-page() sondern mit einer Variable, die in der Seitenvorlage der ersten Seite mit <AtPageCreation> zurückgesetzt wird. Hier gibt es dann das Problem, wenn das Einzeldokument (im Beispiel Briefe, die immer Vorder- und Rückseite haben) eine ungerade Seitenanzahl hat. Entweder man fügt eine Leerseite an oder es treffen zwei ungerade Seiten aufeinander. Im letzteren Fall führt eine Auswertung even/odd von sd:current-page() zum falschen Ergebnis, da muss man die zusätzliche Variable auswerten.

Patrick Gundlach
@pgundlach
@jorg.l_gitlab Wenn das Verhalten nicht korrekt ist, kannst du einen Bug-Report auf https://github.com/speedata/publisher/issues anlegen?
Joerg
@jorg.l_gitlab
Muss ich da jetzt extra einen GitHub-Account anlegen?
Patrick Gundlach
@pgundlach
Du kannst mir auch minimale Layout/Daten mit einer exakten Fehlerbeschreibung schicken.
Joerg
@jorg.l_gitlab
Minimales Layout/Daten sind dieselben, die du schon hast. Vers. 4.3.16 verhält sich folgendermaßen: Ändere ich die Zahl bei dummytext so, dass eine gerade Seitenzahl entsteht, z. B. dummytext(16), dann wird am Ende die fehlerhafte leere Seite angefügt. Bei einer ungeraden Seitenzahl, z. B. dummytext(27), ist alles in Ordnung.
Patrick Gundlach
@pgundlach
Created #330
Demosteneus
@Demosteneus

Hi, I am getting a strange error when publishing:
"! error: (nodes): fuzzy token cleanup in whatsit node with type whatsit and subtype 16"

I think it is related to my data, and not my layouts.
Do you have an idea what this means? Any hints where and what I should be checking?

Patrick Gundlach
@pgundlach
No, sorry. No idea.
I am currently offline, I will take a look tonight
Demosteneus
@Demosteneus

Hi, for another layout I am not getting any errors in the log or the protocol file. The status file just says: "Error executing sdluatex"
If I run with sp.exe --verbose and the only additional error I get is: "panic: runtime error: index out of range [1783633393] with length 1073741824"

any idea why this happens? This layout used to work before.

Patrick Gundlach
@pgundlach
@Demosteneus can you try with sp --option xmlparser=lua, I assume this works fine
@Demosteneus and for the fuzzy token cleanup: whatsit subtype 16 is used for all drawing commands (rules, colors), so that could be anything.
Demosteneus
@Demosteneus

@Demosteneus can you try with sp --option xmlparser=lua, I assume this works fine

Yes this worked. But how can I know beforehand which option will work?
For some data and layouts it works without this option.
For some it works only with this option.
Is there any way to know which option will work?

Patrick Gundlach
@pgundlach
the option xmlparser=lua is the old behaviour (works only since the current version). without this option or xmlparser=go, the speedata Publisher uses a new, not well enough tested XML parser
Demosteneus
@Demosteneus

@Demosteneus and for the fuzzy token cleanup: whatsit subtype 16 is used for all drawing commands (rules, colors), so that could be anything.

I fixed this error. In my case I think it was related to some links (that I had colored blue) and also I was forcing them to not be split on multiple lines with NoBreak.
As soon as I removed the NoBreak for the links this error was gone.

Patrick Gundlach
@pgundlach
it should always work with the old parser (no changes) but should eventually and hopefully with the new XML parser (as this is more strict and adds line numbers/column numbers)