Activity for GraphicsMagick
-
tal posted a comment on ticket #85
As I say I didn't write the test port. Here is the code for the test port: https://github.com/microsoft/vcpkg/blob/master/scripts/test_ports/vcpkg-ci-graphicsmagick/portfile.cmake https://github.com/microsoft/vcpkg/blob/master/scripts/test_ports/vcpkg-ci-graphicsmagick/project/CMakeLists.txt I think you and Kai should talk and understand what happening.
-
Bob Friesenhahn posted a comment on ticket #85
I am not sure what the test port may be, but I see that there is an argument error related to the 'sysroot' directory in the error output. It seems that perhaps part of the arguments is empty where it should have a value and so it is given '-arch' instead. Be sure to specify PKG_CONFIG_PATH to tell pkg-config where to search for its configuration, which needs to match the architecture and the compiler. This could be specified in the overall environment, but it can also be specified as an argument...
-
Thank you for the fix. Now it fail as before on the test port, that it give in the config the arch as library on osx. the x64-osx and arm64-osx logs: https://artprodwus21.artifacts.visualstudio.com/A6adfb432-9816-4cb2-8190-03885865e0d9/c1ee48cb-0df2-4ab3-8384-b1df5a79fe53/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL3ZjcGtnL3Byb2plY3RJZC9jMWVlNDhjYi0wZGYyLTRhYjMtODM4NC1iMWRmNWE3OWZlNTMvYnVpbGRJZC8xMTkxNzYvYXJ0aWZhY3ROYW1lL2ZhaWx1cmUrbG9ncytmb3IreDY0LW9zeA2/content?format=zip https://artprodwus21.artifacts.visualstudio.com/A6adfb432-9816-4cb2-8190-03885865e0d9/c1ee48cb-0df2-4ab3-8384-b1df5a79fe53/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL3ZjcGtnL3Byb2plY3RJZC9jMWVlNDhjYi0wZGYyLTRhYjMtODM4NC1iMWRmNWE3OWZlNTMvYnVpbGRJZC8xMTkxNzYvYXJ0aWZhY3ROYW1lL2ZhaWx1cmUrbG9ncytmb3IrYXJtNjQtb3N40/content?format=zip...
-
Tal, I am confused about your comment about merge requests on the oss-fuzz repo at Github. The oss-fuzz repo is in git and my primary usage (using my fork) is to use it perform merge requests for files under 'projects/graphicsmagick'. My bad, I now understand that you talking about this repo: https://github.com/google/oss-fuzz
-
I was talking about this repo: https://foss.heptapod.net/graphicsmagick/graphicsmagick This repo is hg. and I cannot fork it. Where you have a git repo? Forking is not possible for Mercurial projects yet.
-
To the best of my knowledge, Github provides no support at all for prepared releases (which include generated files and accurate time-stamps). It only provides downloadable tarball/zip of files matching a specified release tag. I am not sure about it. I know people create a release tag with releae tarball/zip file. But you can maybe create a generated files and accurate time-stamps inside the ci, then release it under a tag? You can ask google and chatgpt. I am sure there is a solution. I think curl...
-
I was talking about this repo: https://foss.heptapod.net/graphicsmagick/graphicsmagick This repo is hg. and I cannot fork it. Where you have a git repo?
-
PCL format "errors"
-
It is decided that GM's output is OK but system and printer specific configuration may be necessary in order to not corrupt it. In particular a "classic" printer driver intended for ASCII text is likely to interpret line feed or new line characters.
-
Tal, I am confused about your comment about merge requests on the oss-fuzz repo at Github. The oss-fuzz repo is in git and my primary usage (using my fork) is to use it perform merge requests for files under 'projects/graphicsmagick'. To the best of my knowledge, Github provides no support at all for prepared releases (which include generated files and accurate time-stamps). It only provides downloadable tarball/zip of files matching a specified release tag.
-
Mercurial changeset 17774:06e642b17f41 removes quoting of PNG_LIBS which prevented white-space splitting it into arguments. At one time this part was working so I must have added the quoting not long before submitting my previous changeset. Also, I noticed that my pkg-config libpng configuration was not sufficient to test the feature and so it became silently broken after the bad edit and appeared to be working. Please test again!
-
GraphicsMagick released /graphicsmagick-snapshots/GraphicsMagick-1.4.020250818.tar.xz
-
-
-
-
Bob Friesenhahn committed [06e642] on Code
configure.ac: Remove quoting of PNG_LIBS which prevented white-space splitting it into arguments.
-
It recognize the png, but now it not recognize vsnprintf. not sure why. I give you the logs to check. linux and osx x64 to check. ./../src/5cfbe65a7c-e6cf7a0198.clean/magick/draw.c:439:6: error: Neither vsnprintf or vsprintf is available. 439 | # error Neither vsnprintf or vsprintf is available. | ^ https://artprodwus21.artifacts.visualstudio.com/A6adfb432-9816-4cb2-8190-03885865e0d9/c1ee48cb-0df2-4ab3-8384-b1df5a79fe53/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL3ZjcGtnL3Byb2plY3RJZC9jMWVlNDhjYi0wZGYyLTRhYjMtODM4NC1iMWRmNWE3OWZlNTMvYnVpbGRJZC8xMTkxNzIvYXJ0aWZhY3ROYW1lL2ZhaWx1cmUrbG9ncytmb3IreDY0LWxpbnV40/content?format=zip...
-
It recognize the png, but now it not recognize vsnprintf. not sure why. I give you the logs to check. linux and osx x64 to check. ./../src/5cfbe65a7c-e6cf7a0198.clean/magick/draw.c:439:6: error: Neither vsnprintf or vsprintf is available. 439 | # error Neither vsnprintf or vsprintf is available. | ^ https://artprodwus21.artifacts.visualstudio.com/A6adfb432-9816-4cb2-8190-03885865e0d9/c1ee48cb-0df2-4ab3-8384-b1df5a79fe53/_apis/artifact/cGlwZWxpbmVhcnRpZmFjdDovL3ZjcGtnL3Byb2plY3RJZC9jMWVlNDhjYi0wZGYyLTRhYjMtODM4NC1iMWRmNWE3OWZlNTMvYnVpbGRJZC8xMTkxNzIvYXJ0aWZhY3ROYW1lL2ZhaWx1cmUrbG9ncytmb3IreDY0LWxpbnV40/content?format=zip...
-
on github there is a free ci github action that you can form, and test your build on windows / linux / osx for free. think about to switch all the project to git and github, and leave hg from behind. you can also stay on oss-fuzz. just change the repo to git. I cannot clone it, because it mercury source control (hg) and create a PR (merge request) on oss-fuzz repo. (not even here).
-
on github there is a free ci github action that you can form, and test your build on windows / linux / osx for free. think about to switch all the project to git and github, and leave hg from behind. you can also stay on oss-fuzz. just change the repo to git. Now I cannot even clone it, and give a PR (merge request) on this repo. (not even here).
-
on github there is a free ci github action that you can form, and test your build on windows / linux / osx for free. think about to switch all the project to git and github, and leave hg from behind.
-
I am testing this commit now: https://github.com/microsoft/vcpkg/pull/46958
-
At least during the oss-fuzz build, something is keeping this new feature from working as expected.
-
What about to switch to github? as open source you get everything free, also you can put your website on github https://docs.github.com/en/pages/quickstart
-
-
-
-
-
Mercurial changset 17773:4d3e6e55317d should solve the problem that pkg-config produced PNG_LIBS includes arguments other than the PNG library. Please let me know if this solves the issue for you, and if you see any unexpected output from the configure script.
-
Bob Friesenhahn committed [4d3e6e] on Code
configure.ac: Extract the library name (e.g. -lpng16) from PNG_LIBS.
-
I am lack the knowladge of giving you good answer. I know you can seperate the arguments with pkg-conf by: pkg-config --libs-only-l pkg-config --libs-only-L pkg-config --libs-only-other on vcpkg You need them all. also the only-other that give you direct path to library itself. for example path/to/lib.a The pkg-config --libs is equvalnet to all 3 above. Also there is a tag specific for static: pkg-config --static as I say I lack the knowledge how to do it correctly. Kai know better then me.
-
My Github user id is 'bobfriesenhahn'. It seems that there is more for me to do for this particular request. The PNG_LIBS variable containing info from pkg-config may contain arguments other than -l (e.g. -L) or additional dependency libraries (as you discovered), and so it is necessary to scan the list for a first -l argument and assume that this is the primary dependency. It is possible that there is more than one -l argument for some library dependency that the configure script did not anticipate....
-
Thank you. I have some results. The fix you did seems to work, but on osx it failed on the test port, meaning some of the config give -larm64 as library by mistake. On windows it not tested with the test port, because it generated new absolute paths. in vcpkg we fix them to be relative, and I didn't fix those. I am waiting for linux. I will show you the arm64-osx and x64-osx log. But in the next version we still patch the graphicsmagick to deal with other library names. I not the one that build the...
-
I have pushed Mercurial changeset 17772:6215a223de13 which requires 2.71.
-
Bob Friesenhahn committed [6215a2] on Code
configure.ac: Require Autoconf 2.71 (or later)
-
Based on what I am seeing at https://repology.org/project/autoconf/versions and the Autoconf NEWS file, I will change the version request to 2.71. The 2.69 version is from 2012 and I expect that it won't work anymore given my updates.
-
There is no reason for 2.72 other than that is what I am using at the moment.
-
I patch it for support autoconf 2.71. Any reason why autoconf 2.72?
-
What version of Autoconf do you have? Probably 2.72 is not an absolute requirement and I can find an older version number which supports the requirements. Change the line AC_PREREQ([2.72]) so it says 2.69 and see what happens.
-
I cannot test it. On local and vcpkg ci: configure.ac:14: error: Autoconf version 2.72 or higher is required https://github.com/microsoft/vcpkg/pull/46958 on my local: Can it done with autoconf 2.71? autoconf --version autoconf (GNU Autoconf) 2.71 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+/Autoconf: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html, https://gnu.org/licenses/exceptions.html This is free software: you are free to change and redistribute it. There is...
-
I cannot test it. On local and vcpkg ci: configure.ac:14: error: Autoconf version 2.72 or higher is required https://github.com/microsoft/vcpkg/pull/46958
-
Fix detection of png debug
-
Tal, please test with Mercurial changeset 17771:a5e10a7b2c95 or source snapshot GraphicsMagick-1.4.020250816 and let me know if the configure script works for you now. There are surely other cases where the pkg-config provided library name is not used. I will address those later. The PNG case is by far the most complex since it tests for multiple library names, and verifies that the header file is compatible with the library. The configure script verifies successful linkage before adding a library...
-
-
-
-
-
Bob Friesenhahn committed [a5e10a] on Code
When libpng information is provided by pkgconf (pkg-config), use only the library name that pkgconf provides.
-
the suffix name d in the png in debug, coming from upstream. not from vcpkg.
-
the suffix name d in the png, coming from upstream. not from vcpkg.
-
We aware of it, that why there is much bigger patch. How you can think you need to solve it in the general case, that in pkg-config it give you the correct library name with the suffix if exist. (d for example)? You can also comment on this link: https://github.com/microsoft/vcpkg/pull/46839 Kai can explain better then me how to deal with the problem, also suggest a better solution for you.
-
A challenge I am seeing is that pkg-config may return results equivalent to (for respective configure sections): PNG_LIBS=-L/work/lib -lpng16 -lm -lz FREETYPE_LIBS=-L/work/lib -lfreetype -lbz2 -lpng16 -lm -lz It is strongly desired to verify that it is possible to successfully link with the added library before deciding to use it, and to verify header inclusion given the provided header search paths. It is necessary for configure to support fully-static builds, which makes configuration more challenging....
-
The zip file I post here have both configure as well config.log. the names for that is: config-x64-linux-dbg-out.log config-x64-linux-dbg-config.log The log file taken from vcpkg ci, target for linux build on linux. The PKG_CHECK_MODULES is correct, it taken the correct library name -lpng16d The wrong is in the lines I comments that take hardcoded name: LIB_PNG="-l${pnglib}"
-
The zip file I post here have both configure as well config.log. the names for that is: config-x64-linux-dbg-out.log config-x64-linux-dbg-config.log The log file taken from vcpkg target for linux build on linux. The PKG_CHECK_MODULES is correct, it taken the correct library name -lpng16d The wrong is in the lines I comments that take hardcoded name: LIB_PNG="-l${pnglib}"
-
The console output from 'configure' as well as the final 'config.log' file would be great. Are these vcpgk builds (presumably targeting Windows) being done on Linux? If so, that is interesting. Clearly there is a problem in that PKG_CHECK_MODULES is used to query "libpng" and then it appears to go into detailed code which is testing for specific versions of libpng. What should happen is if pkg-config finds a libpng, then it should use that data rather than then manually trying to determine correct...
-
I cannot repreduce the error on my local, because on my local, on debug it take the release and debug path, and found the release symbol. On vcpkg ci, it doing correctly, only take the debug path: this file taken from my PR: https://github.com/user-attachments/files/21561500/failure.logs.for.x64-linux.zip Inside the file: config-x64-linux-dbg-config.log: see the error that it search for -lpng16 together with -lpng16d because you hard coded the library name: configure:27523: checking for jpeg_read_header...
-
I cannot repreduce the error on my local, because on my local, on debug it take the release and debug path, and found the release symbol. On vcpkg ci, it doing correctly, only take the debug path: this file taken from my PR: https://github.com/user-attachments/files/21561500/failure.logs.for.x64-linux.zip Inside the file: config-x64-linux-dbg-config.log: see the error that it search for -lpng16 together with -lpng16d because you hard coded the library name: configure:27523: checking for jpeg_read_header...
-
Do you want the logs without the patches? to see what happen? on linux?
-
vcpkg doese use and support pkg-config information. I actually switch to built in upstream build system aka configure-based build, because I want to use the pc file that generate, that I will detected by octave. On the unofficial cmake, we didn't generate the pc files, we did instead export cmake files that do the equivalent but only with cmake. What logs are you looking for? Maybe I can generate it on my local. I have windows and linux.
-
Is it correct that the vcpkg build does not support/use pkg-config information? I did not see any GraphicsMagick configure logs in the two pull requests provided above. Being able to see the intermediate test steps/results in the failing configuration would be useful.
-
I don't have now a good answer for you. It needed more time for investigate. How octave do it? Can you find out? https://github.com/gnu-octave/octave
-
To put it in perspective, 1.4G is large enough to support an operating system installation! Bandwidth is not extremely fast or free for everyone, and so 1.4GB (or 1.7GB) is a huge price to pay as compared with 303MB. The Git repository history is not the same as Hg because each branch was translated/copied independently so the tree history of the merging between the branches (which unfortunately is how I decided to produce releases) is lost. The GM repository is likely cloned at least tens of times...
-
When I clone your repo, I use git-remote-hg. Yes it take around 1.7G but this is ok for me. I ratter use the git, then use the hg. Why it important for you that it take 1.4G? Then it give you all the history with all the tags as you see it. But in mirror is different, when you push a commit in your hg repo, it automatic take the commit and save it on github. https://githgmirror.com/ https://stackoverflow.com/questions/12559517/how-to-mirror-hg-repo-to-git-repo https://superuser.com/questions/383366/how-to-make-automatic-git-mirror-for-hg-repo...
-
Someone did create a git clone of GraphicsMagick Hg, but it requires 1.4GB space! I am not sure how to reduce that without spending a few weeks figuring out how to create a new Hg repository which still contains all of the important history and release tags but with shorter branches. If there is an Hg to Git translator which follows the full chronological revision history (including all branches) rather than converting one branch at a time, then the result would surely be much smaller.
-
Robert Bednar posted a comment on ticket #756
HP Support Community and raster graphics/line feeds Image Data and Line Feeds: One particular discussion on the HP Support Community focuses on the issue where the HP LaserJet Pro M118-M119 dw printer interprets a "line feed" character (0A Hex) within raster image data as an actual line feed, disrupting the image instead of ignoring it as part of the data. This issue appears to be specific to certain HP printers, as other PCL5 compatible printers do not exhibit this behavior. PCL5 and Raster Mode:...
-
I was using search terms like: "linefeed characters disrupt PCL raster graphic" -- the solution could be to update the printer drivers. I think the printers like my HP have PCL interprettation baked into the firmware...which may...or may not have an available update. My printer is fine, but the corporate printers (probably older) not so much.
-
If you take a look on my PR, I removed the unofficial cmake build that was before. You can use that as a reference if you are want to go to cmake build.
-
You may have noticed that magick/magick_types.h.in now has no configurable values at all since development GM now requires working C'99 support I notice that, I didn't sure how it will effect vcpkg build. But will deal with that when you do a next release. It is a goal to reduce the configuration complexity and eventually support alternative build mechanisms such as CMake or meson. I would love to see your project move to cmake or meson. (and also git ...).
-
Thanks for providing me with some context. Sorry for not replying earlier. I thought that I had replied but found that my message still remained in the browser widow and had not been submitted. I was not aware that vcpkg was able to support anything other than CMake. It is interesting that you are using the configure-based build. You may have noticed that magick/magick_types.h.in now has no configurable values at all since development GM now requires working C'99 support. It is a goal to reduce the...
-
I've added some relevent files in the attached zip. I created the PCL image on "my" local system, and I tested it on my HP Printer ...and it prints perfectly. I've also uploaded the PCL to an online PCL viewer...and it displays perfectly. There is technically nothing wrong with the output of Graphics Magick. It meets the PCL specification perfectly :-) -- Unfortunately as you surmised...not every printer's PCL interpretter or System Print Driver is created equally. The resultant PCL Logo was uploaded...
-
I've added some relevent files in the attached zip. I created the PCL image on "my" local system, and I tested it on my HP Printer ...and it prints perfectly. I've also uploaded the PCL to an online PCL viewer...and it displays perfectly. There is technically nothing wrong with the output of Graphics Magick. It meets the PCL specification perfectly :-) -- Unfortunately as you surmised...not every printer's PCL interpretter or System Print Driver is created equally. The resultant PCL Logo was uploaded...
-
At this time, I am not assuming that there is a bug in GraphicsMagick's PCL writer, or even a reasonable work-around which may be done in the GraphicsMagick PCL writer. If I enter this query in Google: "printer PCL defend against line feeds", then even the AI response is useful, and I see OS and printer specific adjustments intended to solve this common problem.
-
I am a vcpkg contribute to graphicsmagick. You add hardcoded the libpng library name. In libpng debug the library name there is a d suffix you ignore, and it already detected before. This hardcoded library names is done for other libraries as well. You can learn more from my PR and the next PR that fix it, and take a look on the patches. You can also comments there, the community will help you understand it better. Better comment on the second link https://github.com/microsoft/vcpkg/pull/46725 https://github.com/microsoft/vcpkg/pull/46839...
-
Looking at the documentation from a sample printer (Lexmark MS812), I see PCL emulation settings which enable adding a carriage return after a line feed, or adding a line feed after a carriage return. Both of these default to off. This suggests that other printers may allow adjusting how input is manipulated.
-
Tal, I expect that you would not have submitted this patch unless there is a problem with the very complex libpng configure code. However, the patch seems to be disabling two very important lines of code. I will study the libpng configuration code some more. Can you please post the output of the configure script when it is encountering the issue that your patch is addressing?
-
Please attach a sample input image wrapped in a zip or tar.gz file in order to defend it from modification from SourceForge. This will allow me to reproduce the PCL output. What operating system and printer driver subsystem are you using? What printer are you using? While I will research ways to defend the PCL output from being interpreted as a line feed, it is quite possible (even likely) that the operating system printer driver is responsible for causing this issue. If the operating system printer...
-
-
-
-
-
Bob Friesenhahn committed [fd8849] on Code
magick/utility.c (MagickCreateDirectoryPath): Microsoft Windows mkdir() does not accept a directory mode argument.
-
PCL format "errors"
-
Bob Friesenhahn committed [aadc8a] on Code
Quiet warnings noticed under Microsoft Windows with GCC 15.
-
Fix detection of png debug
-
Bob Friesenhahn committed [131da2] on Code
coders/png.c WriteOnePNGImage(): Fix sign-compare warnings.
-
-
-
-
-
Bob Friesenhahn committed [66e79f] on Code
coders/svg.c ReadSVGImage(): Defend against what appears to be a failure of xmlStopParser() to cause a stop in development libxml2.
-
Bob Friesenhahn committed [0fe23c] on Code
magick/render.c DrawImage(): Handle token memory allocation failure. Do not ignore DrawPatternPath() failure.
-
There have been more advancements to the PNG8 writer but latest ImageMagick 7 (7.1.2-1 (Beta) Q16-HDRI) is doing considerably better than GraphicsMagick when dealing with the "dirty" image. ImageMagick makes the "dirty" image look clean when written to PNG8. Perhaps ImageMagick is considering what a semi-transparent pixel might look when composed on the background color.
-
-
-
-
-
Bob Friesenhahn committed [80d1fd] on Code
coders/png.c WriteOnePNGImage(): Use colormap index rather than grayscale value. Replace semi-transparent colors which are very close to the transparent background color, with the transparent background color
-
Bob Friesenhahn committed [4eeba3] on Code
coders/png.c WriteOnePNGImage(): Pass colormap index for Palette image when writing bKGD chunk
-
Reuben Thomas posted a comment on ticket #755
The image was AI-generated, I believe, so the dirtiness is not surprising. The ImageMagick issue https://github.com/ImageMagick/ImageMagick/issues/8200 has not been updated since the day I filed it. I'm not clear whether the promised change was merged, but there's nothing to indicate that it has been.
-
Ruben, as a reminder, your sample image is very "dirty". The colors meant to be transparent are not very consistent. The image can not be saved efficiently as PNG8 without manipulating pixel values. Did you ever discover what the ImageMagick project did for you? I did not see anything useful in the GitHub comments.
1 >
