Pergunta

Estou tendo problemas para produzir e enviar gráficos para uma impressora EPL2.

Tendo cansado literalmente qualquer pedaço de software disponível e arrastado na Internet, estou perdido.

Eu tenho um arquivo de 1 bit que tento fazer com o script a seguir.

setppi.txt

GK"NAMEPCX"
GK"NAMEPCX" 
GM"NAMEPCX"3042

e depois faça o upload com

copy setppi.txt+ppirmt.pcx lpt1/b

Alguém com experiência tem alguma dica antes de eu arrancar o que restam do meu cabelo? Estou quase certo de que esse problema tem a ver com a criação do PCX, mas, depois de tentar todas as opções, não tenho certeza do meu próximo passo.

Foi útil?

Solução

Aqui está a maneira que encontrei para criar o PCX corretamente:

No GIMP, salve o arquivo como um BMP de 1 bit (preto e branco). Não selecione PCX porque o formato salvo não é PCX de 1 bit, conforme exigido pela impressora!

Use o programa Convert da ImageMagick para converter seu BMP em PCX.

A outra questão que encontrei depois que eu o abaixei foi que os gráficos ainda estavam corruptos, isso era um problema de codapa, então cuidado com isso.

Outras dicas

Você não menciona qual linguagem de programação está usando.

Se for C# (ou .NET em geral), aqui está um post sobre impressão de imagens com o EPL:
Usando o comando EPL2 GW para enviar uma imagem para uma impressora térmica de zebra

E outra postagem do blog do mesmo cara, Isso me fez começar com a impressão de impressoras EPL para Zebra com C#.

Existem duas maneiras de produzir gráficos PCX usando o idioma EPL2. O primeiro é o que você sugeriu:

GK"namepcx"
GK"namepcx"
GM"namepcx",3042
..... and here follows monochrome PCX data ...
..... with 128-bit header and following pixel data 1 bit-per pixel..

mais tarde você deve ser capaz de escrever este armazenado "Namepcx" Para o buffer de imagem da impressora via GM, no entanto, passei dois dias tentando armazenar o PCX, mas nunca seria armazenado corretamente. Então eu acabei simplesmente usando GW comando para gravar dados de pixel diretamente no buffer de imagem de impressoras. Evitando "armazenar na memória flash". Originalmente, este armazenamento "flash" via GM foi destinado a armazenar alguma imagem (como o logotipo) que repetiria em todos os rótulos. Assim, você pode armazená -lo uma vez e imprimir 10 000 rótulos com o mesmo logotipo. No entanto, se houver por disputar o Java, geralmente você imprimia muitas imagens diferentes em rótulos diferentes. Assim, se você armazenar para exibir uma nova imagem para cada rótulo, você "desgastará" a memória flash muito rapidamente. (Por exemplo, o manual da impressora LP 2824 diz que a memória flash tem apenas 100k de ciclos de gravação).

Portanto, pode parecer que usar GW Para escrever o Imag diretamente no buffer de imagem em vez de usar 3 etapas GK GM GG pode ser uma solução melhor.

Isenção de responsabilidade: atualmente estou escrevendo um SVG-para-EPL-Transpiler, que pode ser encontrado aqui

Eu estava enfrentando o mesmo problema ultimamente e resolvi com o envio de um GW-Comando para a impressora.

A principal diferença para GK-GK-GM-GG é que você não envia o cabeçalho PCX, mas os dados binários brutos (AFAIK sem compactação de LRE).

Eu usei o código C# seguinte (não otimizado/ingênuo), que usa fortemente a mudança de bits. O algoritmo pode ser implementado em qualquer idioma e é direto:

[NotNull]
public IEnumerable<byte> GetRawBinaryData([NotNull] Bitmap bitmap,
                                          int octetts)
{
  var height = bitmap.Height;
  var width = bitmap.Width;

  for (var y = 0;
        y < height;
        y++)
  {
    for (var octett = 0;
          octett < octetts;
          octett++)
    {
      var value = (int) byte.MaxValue;

      for (var i = 0;
            i < 8;
            i++)
      {
        var x = octett * 8 + i;
        var bitIndex = 7 - i;
        if (x < width)
        {
          var color = bitmap.GetPixel(x,
                                      y);
          if (color.A > 0x32
              || color.R > 0x96 && color.G > 0x96 && color.B > 0x96)
          {
            value &= ~(1 << bitIndex);
          }
        }
      }

      yield return (byte) value;
    }
  }
}

O que você deve ter em mente para as conversões:

  • 1: ponto branco
  • 0: DOT preto
  • width tem que ser um múltiplo de 8 (como estamos enviando bytes) - o código acima cuida disso preenchendo
  • rotação/orientação do rótulo!
  • Algum limite é implementado aqui ...

Eu também implementei GM-GG, mas isso iria além do escopo desta resposta. O código relevante pode ser encontrado em EplCommands.StoreGraphics(bitmap:Bitmap,name:string).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top