O trabalho começou com uma premissa aparentemente natural: se o rótulo precisava ser impresso pelo Protheus, deveríamos utilizar os recursos de impressão oferecidos pelo próprio Protheus.
A `FWMsPrinter` foi, portanto, a primeira escolha. Ela já fazia parte do ambiente, possuía métodos para impressão de textos, imagens e códigos de barras e, em teoria, reunia tudo o que seria necessário.
Nos primeiros modelos, os resultados pareciam confirmar essa decisão. Com coordenadas, fontes e dimensões cuidadosamente calculadas, era possível aproximar a impressão do layout esperado. Cada diferença visual parecia solucionável com mais um ajuste: alguns milímetros na posição, uma redução no tamanho da fonte, uma nova proporção ou uma compensação específica para determinado modelo.
Entretanto, conforme os rótulos foram ficando mais complexos, a natureza do problema começou a mudar.
Já não estávamos simplesmente configurando uma impressão. Estávamos tentando utilizar uma ferramenta genérica de relatórios como se ela fosse uma engine especializada em composição gráfica de etiquetas.
### O ciclo dos ajustes sucessivos
Nos modelos com códigos de barras horizontais, ainda era possível obter resultados aceitáveis. Nos modelos 2 e 9, porém, o código precisava ser impresso verticalmente.
O método `FWMsBar`, que teoricamente deveria atender a essa necessidade, não apresentou comportamento consistente nas configurações testadas. Dependendo da orientação, das dimensões ou da combinação de parâmetros, o código de barras não era impresso, ficava deslocado ou apresentava uma aparência visual diferente daquela esperada.
A tentativa natural foi compensar essas diferenças pelo código.
Foram necessários cálculos para:
- Converter unidades de medida;
- Determinar largura e altura úteis;
- Compensar rotações;
- Recalcular posições após a mudança de orientação;
- Ajustar margens internas;
- Redimensionar textos conforme o conteúdo;
- Conciliar métricas de fontes;
- Evitar sobreposição entre volume, espécie, dados variáveis e código de barras;
- Adaptar cada modelo individualmente.
Cada correção resolvia uma situação específica, mas frequentemente criava outra. Uma configuração funcionava para determinado conteúdo e falhava quando o volume aumentava. Uma fonte parecia adequada para uma espécie curta, mas ultrapassava a área disponível quando recebia uma descrição maior. Um código de barras ficava corretamente posicionado em uma página e deslocado em outra.
Era a sensação técnica de estar “correndo atrás do próprio rabo”: mais código, mais cálculos e mais exceções, sem que isso produzisse uma garantia proporcional de estabilidade.
### A limitação não estava apenas nos cálculos
Seria possível continuar acrescentando condições específicas:
```text
Se for o modelo 2, deslocar alguns milímetros.
Se for o modelo 9, inverter largura e altura.
Se o texto ultrapassar determinado tamanho, reduzir a fonte.
Se estiver rotacionado, aplicar uma nova compensação.
```
O problema é que esse tipo de abordagem não elimina a causa. Ele apenas adiciona novas camadas de compensação sobre uma ferramenta que não foi concebida especificamente para esse cenário.
A dificuldade era agravada pelo caráter proprietário dos componentes envolvidos e pela ausência de documentação completa sobre pontos essenciais, principalmente:
- Interpretação exata das dimensões;
- Sistema de coordenadas após uma rotação;
- Origem utilizada para posicionamento;
- Comportamento das margens internas;
- Métricas efetivamente adotadas para as fontes;
- Relação entre resolução lógica e resolução do dispositivo;
- Redimensionamento automático de imagens;
- Área considerada pelo código de barras;
- Diferenças entre visualização, PDF e impressão física;
- Limitações específicas de cada driver e ambiente.
Sem acesso integral ao funcionamento interno da ferramenta, parte relevante do desenvolvimento acabava baseada em experimentação: alterar, compilar, executar, gerar o PDF, conferir visualmente e ajustar novamente.
Isso demanda muito trabalho, mas trabalho e previsibilidade não são necessariamente proporcionais.
Quanto mais exceções eram adicionadas, maior se tornava o custo de manutenção. Uma alteração para corrigir um modelo poderia afetar outro. Uma nova espécie ou um volume fora do padrão poderia exigir outro ciclo de testes. O programa começava a concentrar não apenas as regras de negócio, mas também toda a geometria dos rótulos.
### O momento da decisão
Em algum momento, todo projeto técnico precisa responder a uma pergunta desconfortável:
Devemos continuar insistindo na ferramenta originalmente escolhida ou reconhecer que ela se tornou a principal limitação da solução?
Persistência é importante, mas insistência e persistência não são a mesma coisa.
Persistir significa continuar buscando o resultado. Insistir significa repetir o mesmo caminho, mesmo quando as evidências demonstram que ele não oferece os controles necessários.
A decisão de pesquisar outra abordagem não surgiu como uma tentativa de abandonar o Protheus nem de substituir tecnologia por preferência pessoal. Surgiu da constatação de que impressão de etiquetas com composição gráfica, textos adaptáveis e códigos de barras rotacionados exige ferramentas mais especializadas.
Foi necessário interromper o ciclo dos ajustes sucessivos e voltar ao problema original:
- O que efetivamente precisa ser impresso?
- Qual tecnologia possui controle previsível sobre cada elemento?
- Onde devem ficar as regras de negócio?
- Onde deve ficar a responsabilidade pelo layout?
- Como garantir que o resultado seja reproduzível?
### A busca por ferramentas especialistas
A pesquisa levou a uma composição baseada em tecnologias Web, não porque fossem mais modernas, mas porque eram mais adequadas à natureza do problema.
O SVG foi escolhido para definir o layout vetorial. Nele, cada elemento possui coordenadas, dimensões, transformações e estilos explicitamente declarados. O arquivo pode ser aberto, inspecionado e editado por ferramentas gráficas como o Inkscape.
O JsBarcode passou a ser responsável pela geração dos códigos de barras. Em vez de tentar compensar o comportamento de um método genérico de impressão, passou-se a utilizar uma biblioteca criada especificamente para produzir códigos de barras.
O navegador assumiu a medição e o ajuste dos textos. Como é ele quem efetivamente renderiza a fonte, também é o ambiente mais adequado para verificar se determinado conteúdo cabe na largura e na altura reservadas pelo template.
O html2canvas ficou responsável por materializar cada rótulo preparado, enquanto o jsPDF passou a criar e consolidar o documento final.
O TWebEngine e o TWebChannel permaneceram como ponte entre o Protheus e essa camada de renderização.
A nova arquitetura ficou organizada da seguinte maneira:
```text
Protheus
└─ obtém dados e aplica regras de negócio
└─ SVG define o layout
├─ navegador ajusta os textos
├─ JsBarcode gera o código de barras
├─ html2canvas renderiza o rótulo
└─ jsPDF consolida o documento
```
Cada ferramenta passou a executar uma responsabilidade para a qual foi efetivamente projetada.
### A mudança de responsabilidade
Na solução anterior, o programa precisava conhecer a posição de praticamente tudo:
- Coordenada do volume;
- Coordenada da espécie;
- Largura disponível;
- Altura disponível;
- Fonte máxima;
- Fonte mínima;
- Rotação;
- Compensação da rotação;
- Distância entre elementos;
- Posição do código de barras;
- Ajustes específicos de cada modelo.
Na nova abordagem, essas informações pertencem ao SVG.
O Protheus fornece os dados:
- Produto;
- Lote;
- Fabricação;
- Validade;
- Peso;
- Volume;
- Espécie;
- Conteúdo do código de barras.
O template define como esses dados serão apresentados.
Essa separação é importante porque uma alteração visual deixa de exigir necessariamente uma modificação no código-fonte. Se o cliente desejar mover um elemento, alterar uma fonte ou redimensionar o código de barras, a mudança poderá ser realizada diretamente no SVG, preservando o contrato de identificadores utilizado pela integração.
### O tratamento dos textos variáveis
Uma das maiores fontes de complexidade da solução anterior era a elasticidade dos textos.
O tamanho de uma palavra não depende apenas da quantidade de caracteres. Letras diferentes ocupam espaços diferentes. A mesma expressão pode apresentar dimensões distintas dependendo da fonte, do peso, do estilo e do mecanismo de renderização.
Tentar antecipar isso apenas com cálculos no AdvPL exigia aproximações e sucessivas exceções.
No SVG, cada campo pode declarar seus próprios limites:
```xml
data-fit-width="35"
data-fit-height="11"
data-min-font-size="1.2"
data-max-font-size="11"
```
O navegador renderiza o texto, mede sua dimensão real e reduz a fonte até que o conteúdo caiba na área definida.
O cálculo deixa de tentar prever o que acontecerá na renderização. Ele passa a utilizar a própria renderização como referência.
Também foram criados limites de recorte para impedir que textos muito extensos invadam áreas destinadas ao código de barras ou a outras informações.
### O código de barras como evidência da mudança
O código de barras sintetiza bem a diferença entre as duas abordagens.
Com a `FWMsPrinter`, grande parte do esforço estava concentrada em descobrir como o método interpretaria dimensões e rotações em cada contexto.
Com o JsBarcode e o SVG, a responsabilidade foi dividida:
- O template define a área externa disponível;
- O JsBarcode gera barras e texto;
- O `viewBox` normaliza o conteúdo;
- `preserveAspectRatio` controla seu encaixe;
- O navegador realiza a renderização;
- O jsPDF preserva as dimensões físicas da página.
Ainda foram necessários testes e ajustes. A utilização de ferramentas especializadas não elimina o trabalho técnico, mas muda sua natureza. Em vez de compensar comportamentos pouco documentados, passamos a configurar propriedades explícitas e verificáveis.
### O resultado arquitetural
A evolução não se limitou à substituição de um método de código de barras. O processo inteiro foi reorganizado:
- Cada rótulo passou a ser composto em ambiente Web;
- Os modelos SVG assumiram a propriedade do layout;
- Textos passaram a ter ajuste automático;
- Códigos de barras passaram a ser gerados por ferramenta especializada;
- As particularidades dos rótulos internos foram preservadas;
- Campos opcionais passaram a ser controlados declarativamente;
- Os rótulos selecionados passaram a formar um único PDF multipágina;
- O documento passou a ser aberto por Blob;
- O download foi mantido como contingência;
- O consumo de memória passou a ser monitorado;
- Recursos binários passaram a ser reutilizados durante a execução;
- O processo foi documentado para permitir manutenção e criação de novos modelos.
A `FWMsPrinter` foi retirada da composição dos rótulos. Sua utilização residual ficou limitada às métricas necessárias para os modelos raster legados e poderá desaparecer conforme a migração para SVG seja concluída.
### A conclusão
A principal decisão técnica deste projeto não foi escolher SVG, JsBarcode ou jsPDF. Foi reconhecer o momento em que continuar ajustando a solução anterior deixaria de representar avanço.
A `FWMsPrinter` não é uma ferramenta ruim. Ela apenas se tornou a ferramenta limitante para uma necessidade que exige controle gráfico especializado. Continuar criando cálculos, exceções e compensações poderia produzir novos resultados pontuais, mas também aumentaria a complexidade e o risco de regressão.
A alternativa responsável foi pesquisar, estudar e utilizar ferramentas mais adequadas.
Em desenvolvimento de software, experiência não se manifesta apenas na capacidade de fazer uma tecnologia funcionar. Ela também aparece na capacidade de perceber quando o custo de fazê-la funcionar ultrapassa o benefício de continuar insistindo.
Às vezes, resolver um problema exige persistência para avançar pelo caminho atual. Em outras, exige coragem técnica para interromper o ciclo, rever a arquitetura e escolher ferramentas que realmente compreendam o problema que precisam resolver.
---
#DNATech #DesenvolvimentoDeSoftware #ArquiteturaDeSoftware #Protheus #AdvPL #TLPP #TOTVS #FWMsPrinter #SVG #JsBarcode #TWebEngine #JavaScript #GeracaoDePDF #ImpressaoDeRotulos #CodigoDeBarras #TecnologiaWeb #EngenhariaDeSoftware #Refatoracao #SolucaoTecnica #Inovacao #MelhoriaContinua #DecisaoTecnica #FerramentasEspecialistas #QualidadeDeSoftware #Manutenibilidade #ExperienciaDoCliente
Comentários
Postar um comentário