stampare etichette

[andy60]

@dex

io a casa ho una ottima HP Officejet j4680 all-in-one, i driver sono dentro la distribuzione (hplip)

[dex]

aggiornamento.
mi sono ricordato di una vecchia Dymo LabelWriter 400 che usavamo con windows, collegata al pc ubuntu 10.10 l'ha riconosciuta e caricato il driver al volo.
Poi ho installato  gLabels,  questo programmino (in italiano ) aveva al suo interno anche delle Template per le Dymo, in più ha un Template Designer che permette di creare qualsiasi etichetta.
Oltre al testo ha tantissimi codici a barre.

Ora devo solo provare a lanciare la stampa da Gambas con PdfWriter

[dex]

stampate le prime etichette con la Dymo.

unico neo per PdfWriter  è che con le etichette piccole tipo 25 x 25 mm mi crea dei problemi per inserire più righe, in quanto vanno ad accavallarsi Header con  Footer e Data non avendo spazio mi crea più pagine.

allego la prima etichetta

[md9327]

Prova a ridurre i font, e/o a calcolarti la posizione della riga successiva.

[perseo]

Scusate ragazzi,

io ho un problema con il riconoscimento del Barcode (EAN13) di PDFWriter...
Lo stampo (anche in BEST Quality) ma non ne vuol sapere di riconoscerlo.

Stessa stampante, sempre EAN13, stesso numero di codice... generato e stampato con BarCode0.0.7 me lo riconosce.

Ho confrontato i due disegni creati per lo stesso numero, 8711577011208, sia da PdfWriter che da BarCode0.0.7, e mi sembra che siano quasi simili... con la differenza che quello di PDFWriter disegna in mezzo alcune righe differenti da quell'altro.

PS. ho stampati i BarCode del programma Test di PdfWriter (gli esempi che ha fatti MD) ed il barcode-reader non riconosce neppure quelli... 

[dex]

Prova a ridurre i font, e/o a calcolarti la posizione della riga successiva.

gia provato.
con le linee o il Barcode dato che conservano una posizione assoluta  riesco a stampare dove voglio, il problema si presenta solo con Cel, per stampare la prima Cell devo settare Y a -8 e la seconda Cell in automatico mi crea una nuova pagina

[dex]

Scusate ragazzi,

io ho un problema con il riconoscimento del Barcode (EAN13) di PDFWriter...
Lo stampo (anche in BEST Quality) ma non ne vuol sapere di riconoscerlo.

Stessa stampante, sempre EAN13, stesso numero di codice... generato e stampato con BarCode0.0.7 me lo riconosce.

Ho confrontato i due disegni creati per lo stesso numero, 8711577011208, sia da PdfWriter che da BarCode0.0.7, e mi sembra che siano quasi simili... con la differenza che quello di PDFWriter disegna in mezzo alcune righe differenti da quell'altro.

PS. ho stampati i BarCode del programma Test di PdfWriter (gli esempi che ha fatti MD) ed il barcode-reader non riconosce neppure quelli... 

Io non ho provato a leggere il barcode in quanto il lettore è su un'altro pc, prova a leggere il pdf che ho allegato vedi se lo legge, l'ho creato con PdfWriter e Barcode Code39

[perseo]

Grazie mille,
dex... Avevo già provato e non lo legge.

Poi ho riesumato un progetto di Golia e sono riuscito astampare e far leggere il Code39! L'unica cosa è che a me servono codici per "00000000" numeri.. e con code39 vengono troppo lunghi.
Sarebbe ottimo un Code con i25 o con EAN13... a quelli non li legge!

A voi gli EAN13 ed i i25 li legge?

[perseo]

Ce l'ho fatta! Ho risolto sul formato code.i25!  

Ho confrontato il codice a barre generato sull'esempio in php nel sito fpdf.org... e quello generato da Gambas... Li ho stampati e confrontati... quello di gambas è l'esatto negativo di quello in php, infatti il mio lettore laser quest'ultimo lo riconosceva, mentre il codice a barre generato da gambas no.

Nella figura ho usato il numero "12345678" in .i25. Il codice a barre superiore è generato in php, quello sotto era quello di gambas.

Quindi sono andato a vedere il codice della classe PdfWriter, e nonostante io non conosca il php mi pare che MD abbia fatta la traduzione esatta, ma tant'è che se cambiate la riga 2854 della classe PdfWriter da così:

Codice: gambas [Seleziona]

If (bar Mod 2 = 0) Then Me.Rect(xpos, ypos, lineWidth, height, "F")

a così:

Codice: gambas [Seleziona]

If (bar Mod 2 <> 0) Then Me.Rect(xpos, ypos, lineWidth, height, "F")

Il codice a barre generato è perfetto e non mi da più problemi di riconoscimento.

Credo che il codice di programmazione per generare EAN13 abbia problemi simili, perché anche in lì confrontando le stampe ci sono delle leggere discordanze tra le barre (quelle in mezzo).

PS. non è tardi... di più!!! E domattina sveglia alle 7... Però vado a dormire soddisfatto. Ce l'abbiamo fatta!  

[md9327]

Hai fatto un bel lavoro!!! 

Purtroppo il mio lavoro è stato solo quello di tradurre la libreria, e su alcune funzioni aggiuntive non ho potuto fare verifiche.

Introdurrò la tua modifica a breve (mi fido del tuo lavoro...  ), per la prox versione 0.0.5

E' anche probabile che il problema sia lo stesso per le altre funzioni barcode, come tu dici. Proverò a dargli un'occhiata, ma non ho modo di verificare, e il tuo aiuto sarebbe indispensabile per sistemare la libreria, visto che la possibilità di provarlo con gli strumenti adatti.

[perseo]

Grazie MD...

ma la mia è ben poca cosa!



Questo è il confronto tra il codice a barre EAN13 generato in PHP ed il suo corrispettivo generato da PdfWriter in Gambas... Il numero è "123456789012" (l'8 finale viene aggiunto di suo).

Se togli le ultime 2 barre del PHP le restinti 12 combaciano perfettamente con le ultime 12 di Gambas...
E' come se Gambas perdesse un numero alla fine e lo mette all'inizio, ma in maniera casuale stravolgendo la parte iniziale...
Ho provato a rileggere attentamente nel codice, ma non mi pare che ci siano errori.

Ho lanciato un print barcode per verificare che dopo il controllo iniziale il numero barcode venga restituito corretto... ed infatti è "1234567890128"... e quindi il problema deve essere dai cicli finali in poi.

PS. sicuramente non è un problema (visto che le risoluzioni delle stampanti non arrivano a tanto), ma secondo me sarebbe meglio accorpare i rettangoli neri contigui in un unico rettangolo, altrimenti ho notato che da gambas ingrandendo il codice a barre generato si creano delle sottilissime zone di vuoto... In PHP non succede... Puoi confrontarlo nei disegni che ho allegati...
Credo che basterebbe, anziché stampare un rettangolo ad ogni ciclo, un semplice If con una variabile integer che aumenti lo spessore quando se il risultato del ciclo precedente è uguale.

[perseo]

MD...
dagli una controllata. Questa dovrebbe essere la SUB che raggruppa i rettangoli contigui neri, per generare un barcode più omogeneo.

Codice: gambas [Seleziona]

PRIVATE SUB DrawBarcode($code AS String, $x AS Float, $y AS Float, $h AS Float, $w AS Float)
DIM i, j AS Integer = 0
DIM l AS Boolean = FALSE

  $code = $code & "!" ' <--- è finita la stringa
  
  FOR i = 1 TO (Len($code) - 1)
    IF (Mid($code, i, 1) = "1") THEN 
      IF (Mid($code, i + 1, 1) = "!") OR (Mid($code, i + 1, 1) = "0") THEN 
        'stampa il rettangolo
        ME.Rect($x + (i - 1 - j) * $w, $y, $w + j * $w, $h, "F")
        'PRINT i, Mid($code, i, 1), "Stampa " & j
      ELSE 
        INC j
        'PRINT i, Mid($code, i, 1), "Incrementa j"
      ENDIF 
    ELSE 
      j = 0
      'PRINT i, Mid($code, i, 1), "Si sposta"
    ENDIF 
  NEXT 
END

Il codice è sempre ancora sbagliato... però intanto abbiamo migliorato la parte a stampa... 
Nella parte superiore il codice generato con l'aggiunta di questa SUB, sotto senza la SUB...

[md9327]

MD...
dagli una controllata. Questa dovrebbe essere la SUB che raggruppa i rettangoli contigui neri, per generare un barcode più omogeneo.

Codice: gambas [Seleziona]

PRIVATE SUB DrawBarcode($code AS String, $x AS Float, $y AS Float, $h AS Float, $w AS Float)
DIM i, j AS Integer = 0
DIM l AS Boolean = FALSE

  $code = $code & "!" ' <--- è finita la stringa
  
  FOR i = 1 TO (Len($code) - 1)
    IF (Mid($code, i, 1) = "1") THEN 
      IF (Mid($code, i + 1, 1) = "!") OR (Mid($code, i + 1, 1) = "0") THEN 
        'stampa il rettangolo
        ME.Rect($x + (i - 1 - j) * $w, $y, $w + j * $w, $h, "F")
        'PRINT i, Mid($code, i, 1), "Stampa " & j
      ELSE 
        INC j
        'PRINT i, Mid($code, i, 1), "Incrementa j"
      ENDIF 
    ELSE 
      j = 0
      'PRINT i, Mid($code, i, 1), "Si sposta"
    ENDIF 
  NEXT 
END

Il codice è sempre ancora sbagliato... però intanto abbiamo migliorato la parte a stampa...  
Nella parte superiore il codice generato con l'aggiunta di questa SUB, sotto senza la SUB...

Il fatto delle linee non contigue potrebbe dipendere dalla differenza di profondità della risoluzione tra PHP e Gambas, relativamente al tipo di variabile utilizzata.
La tua idea potrebbe non essere male...

Riguardo alle differenze, mi sembra tanto che il colore delle barre venga semplicemente invertito. Se così è, basterebbe invertire la funzione di disegno... E' da controllare...

Sò che lo dico spesso in questo periodo, ma cercherò di studiare la cosa appena possibile, e le tue analisi e i tuoi suggerimenti mi saranno senz'altro utili per sistemare la cosa.

Ho messo in evidenza questa cosa tra i problemi che dovrò sistemare appena possibile.

[perseo]

Mitico!

Occhio che il problema dei colori invertiti era per il code.i25... Ora l'ho corretto e funziona perfettamente (oggi l'ho testato su una 20 di etichette a numero random)

Quello del code.EAN13 invece è proprio un altro problema. Infatti come puoi vedere confrontando l'immagine del codice generato da php con quello generato da gambas la differenza è che sono proprio due disegni differenti, la cui unica similitudine è una zona tra la seconda metà e quella finale. Quindi lì non si tratta di invertire i colori, ma di rivedere il codice.
Io ho ritentato anche oggi, ma non vedo errori, quindi non capisco proprio da cosa possa dipendere. Magari è uno di quei bugs subdoli... che prima o poi uscirà fuori.
Se ti serve una mano, nei limiti del tempo possibile, sono disponibilissimo!

PS. PdfWriter è fantastico!
Ho deciso però di non utilizzare troppo le "cell", ma di disegnarmi direttamente ogni elemento di ogni report alla volta (attraverso i cicli... chiaramente). Sarà una soluzione meno sbrigativa, ma almeno ho il pieno controllo di ogni tassello. Poi, appena sono pronti, metto alcuni allegati. grazie ancora per il lavorone di trascrizione! 

[dex]

PS. PdfWriter è fantastico!
Ho deciso però di non utilizzare troppo le "cell", ma di disegnarmi direttamente ogni elemento di ogni report alla volta (attraverso i cicli... chiaramente). Sarà una soluzione meno sbrigativa, ma almeno ho il pieno controllo di ogni tassello. Poi, appena sono pronti, metto alcuni allegati. grazie ancora per il lavorone di trascrizione!

PdfWriter ha fatto un'altra vittima!!  

Se non riesci a leggere il Code39 allora anche quello ha qualche errore!!

Edit: l' i25 accetta solo numeri, con le lettere va in errore.