[Koha-devel] [Koha] barcodes,

[Chris Nighswonger]

On Fri, Jul 3, 2009 at 2:20 PM, Chris Nighswonger <
cnighswonger at foundations.edu> wrote:

> On Fri, Jul 3, 2009 at 1:14 PM, Joe Atzberger <ohiocore at gmail.com> wrote:
>
>> Note: This would dramatically increase the resulting filesize and the
>> computational cost of delivering it.
>>
>
> Right, roughly an eye-popping 636% larger file size. So if one is printing
> very large label batches (>500 labels) it might not work well for them.
>
> This is really only a workaround. I'm working to try to understand exactly
> what needs to be changed in PDF::Reuse to correct the Type3 issue. I hope to
> have a *real* fix for it in the near future.
>
> As an alternative, this workaround could simply be applied on a
> case-by-case basis rather than committing the patch I submitted to the main
> repo.
>
>

Pursuing this further...

FWIW: It appears that Type 3 fonts are legacy and poorly supported at best.

I did, however, enable PDF::Reuse zip compression directive in combination
with the graphic embedding of the barcodes. This gives an equally
eye-popping 26% *reduction* over non-compressed Type 3 font embedding. ie.
4.5 K/pg (compressed graphic) vs. 17.5 K/pg (uncompressed Type 3 font) vs
111 K/pg (uncompressed graphic). So the issue with increased file size
should now be contained.

It appears that most other applications that export in pdf use compression
by default. (OO Writer, etc.)

I'm submiting an additional patch to enable compression.

Unless there is something I've missed, I'd recommend this as a permenant
fix.

Regards,
Chris




>
>
>> 2009/7/3 Chris Nighswonger <cnighswonger at foundations.edu>
>>
>>> On Sat, Jun 27, 2009 at 4:27 PM, Chris Nighswonger <
>>> cnighswonger at foundations.edu> wrote:
>>>
>>>> On Sat, Jun 27, 2009 at 8:10 AM, mike re-v<mrmrmr50 at yahoo.com> wrote:
>>>> >
>>>> > Greetings,
>>>> > print to file and send it to me, I'll see if I can open it.
>>>> > Alternatively, hexedit will open, it and it could look at the leader
>>>> > and the end byte codes to see what it is you are producing.Then
>>>> compare what you are producing to what works.
>>>> >
>>>> > from the command line $ hexedit foo.pdf
>>>> >
>>>>
>>>> Alternately you can just open the pdf in a plain text editor and check
>>>> to see that the barcode data is there. PDF is a sort of mangled Post
>>>> Script stream.
>>>>
>>>>
>>>> Below is the stream for a single item. The line with the series of
>>>> zeros and ones is the barcode. However, I can confirm that the
>>>> barcodes do not display in Reader 9.0 while they do in 7.0. Versions
>>>> 8.0 and 9.0 use PDF version 1.7 while 7.0 uses 1.6. There may be a
>>>> subtle difference in syntax that causes the breakage. I'll open a bug
>>>> and try to take a look at it next week.
>>>>
>>>
>>> The issue here is not a Koha issue, but *probably* an issue where Adobe
>>> Reader does not maintain backward compatibility. Fortunately the fix is not
>>> so bad. We just switch from embedding the barcodes as a Type3 font to
>>> graphical embedding. I'll submit a patch later today against the current
>>> HEAD. It will need to be back-ported to the 3.0.x branch as well.
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>> _______________________________________________
>>> Koha-devel mailing list
>>> Koha-devel at lists.koha.org
>>> http://lists.koha.org/mailman/listinfo/koha-devel
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090704/43430616/attachment-0003.htm>