Класс для API ZINT «Barcode Generator»

[Игорь Столяров]

Библиотека для создания практически любых штрих-кодов.
В примере показан вывод штрих-кодов в окно и отчёт.

(Перекрестная ссылка на альтернативу viewtopic.php?p=40124#p40124) добавил Admin

[Игорь Столяров]

Я в соседней теме приводил правильную формулу расчета ширины строки...

Абсолютно верно ! И она же описана в FreeImage. И тут же Вы пишите:

Возможно, это какая-то особенность FreeImage.

Когнитивный диссонанс, однако …

[Constantine]

Никакого диссонанса!
Это означает, что FreeImage не умеет работать с 24-бит. Соответственно, перед использованием, нужно конвертировать 24 - 32.
Разве это не особенность?

[Игорь Столяров]

Это означает, что FreeImage не умеет работать с 24-бит

Не буду спорить, т.к. не знаю. Только факты:
- Глубина цвета пикселя указывается в InfoHeader.biBitCount = 24, InfoHeader.biClrUsed = 0 ! (по biBitCount)
- Но сам 24-битный bitmap перед записью в DIB нужно разбивать и растягивать по длине строки.
- Как-то так, иначе не работает. Совсем.

[Constantine]

Но сам 24-битный bitmap перед записью в DIB нужно разбивать и растягивать по длине строки.

Возможно. Зависит от того, что с ним планируется делать дальше. Если показывать во FreeImage, то придется. А если через Clipboard вставлять в Paint - нет.

[Игорь Столяров]

Зависит от того, что с ним планируется делать дальше.

За ClipBoard и Paint не скажу, но так формируется строка для записи в ?Image{Prop:ImageBits} или просто в файл формата BMP.

[kreator]

Ну вы даёте! Я так понял - "растягивание по длине строки" - это превращение 24 бита в 32?

[Игорь Столяров]

это превращение 24 бита в 32

К сожалению нет - это было бы просто и не весело. Посмотрите в ZintClass.BitmapToImage() - что бы не копать в недрах FreeImage.
Вообще графика, её форматы и т.д. - это один из самых древних компонентов ОС. И почти за 40 лет там столько всего наслоилось …

[Constantine]

Я так понял - "растягивание по длине строки" - это превращение 24 бита в 32?

Да, верно. По сути своей, 32-битный bitmap с нулевым значением альфа-канала эквивалентен 24-битному.
Устроены они, правда, по-разному, но на экране будут выглядеть совершенно одинаково.

[Constantine]

но так формируется строка для записи в ?Image{Prop:ImageBits} или просто в файл формата BMP.

Не думаю, что ?Image{Prop:ImageBits} не сможет показать правильно сформированный 24-битный bitmap. Да, если конвертировать 24 - 32 таким образом, как это предлагается здесь, результат будет тот же самый.
То же самое касается и файла: что вы туда запишете, то и получите. Запишете правильно сформированный 24-бит - его и получите; запишете правильно сформированный 32-бит - тоже его и получите.
Судя по всему, разработчики этого самого FreeImage решили не заморачиваться с нормальной поддержкой 24-бит и выкрутились вот таким образом...
Это, однако, совершенно не означает, что так нужно делать всегда.

[Игорь Столяров]

Не думаю, что ?Image{Prop:ImageBits} не сможет показать правильно сформированный 24-битный bitmap

Я шёл по пути практики, а не гипотетических рассуждений о возможностях. А именно:
- Загрузил в строку 24 битный BMP файл сформированный ZINT и разобрал его структуру;
- Добавил метод, который формирует аналогичную строку на основании Bitmap ZINT и записывает её ?Image{Prop:ImageBits}.
- Всё. Вроде бы ничего лишнего или принятого за уши.

[Constantine]

Тогда в чем проблема?
Если есть программа (ZINT), которая корректно формирует 24-битный bitmap, и есть программа, которая его корректно показывает через ?Image{Prop:ImageBits}, зачем что-то куда-то конвертировать? Все должно работать и так...

[Игорь Столяров]

Если есть программа (ZINT), которая корректно формирует 24-битный bitmap

К сожалению это не так. Библиотека ZINT корректно формирует 24-битный BMP ФАЙЛ (!!!) с картинкой штрих-кода.
А вот строку (массив байт) приходится формировать самостоятельно, на основании bitmap (карты памяти) ZINT.

Здесь просто расхождение терминологии. Вы пытаетесь любой набор данных картинки в памяти называть bitmap.

[Constantine]

24-битный BMP ФАЙЛ (!!!) с картинкой штрих-кода

А что мешает считать bitmap прямо из файла в DIB-секцию?
Нужно только сместить указатель начала файла на SIZE(FILEINFOHEADER)+1. Если файл сформирован корректно (открывается на просмотр), все, что идет дальше, до конца файла, и есть то, что Вам нужно.
Какая разница, сколько там бит? Зачем что-то конвертировать?

Здесь просто расхождение терминологии. Вы пытаетесь любой набор данных картинки в памяти называть bitmap.

Никакого расхождения нет. В данном случае, с точки зрения MSDN:
1. BITMAP = BITMAPINFOHEADER + пиксели. Если Вы его разместили в обычной памяти с помощью функции CreateCompatibleBitmap, то он и есть просто bitmap,
2. DIB = тот же самый BITMAP в DIB-секции, ее можно разместить как в обычной памяти, так и в контексте устройства (DC),
3. Файл *.BMP = BITMAPFILEHEADER + тот же самый BITMAP. Он может быть как в оперативной памяти (если Вы его там сформируете), так и на диске.

[kreator]

Constantine, я уже и то понял. Поскольку библиотека ZINT формирует 24-битную "карту" пикселей, с ней работать корректно не получается. Как её не назови, DIB, Bitmap. В любом случае её нужно превращать в 32-битную.

[Constantine]

с ней работать корректно не получается.

Почему?
Если файл корректно открывается на просмотр - все ОК.
Если файл штатным образом корректно вставить в Кларионовский Image, и он будет нормально отображаться - все ОК.