Hello, I have two servers (one x86 and one PPC) that have imagemagick emerged like so: media-gfx/imagemagick-6.2.8.0 USE="gs jpeg mpeg perl png tiff truetype xml zlib -X -bzip2 -doc -fpx -graphviz -jbig -jpeg2k -lcms -nocxx -wmf" Neither of them have the corefont package, as they do not have X (note -X USE). The corefont package is needed for text manipulation functions. Thanks, Rob Kaufman
I _think_ you need fonts, not specific fonts. please reopen with some more information and a testcase.
When running the simple test: convert label:abcde test.gif The result is: convert: unable to read font `/usr/share/fonts/corefonts/arial.ttf'. convert: missing an image filename `test.gif'. It would seem that this should work under the default install. At the least it would seem right to have a corefonts use flag.
fixed in imagemagick-6.2.9.5
imagemagick can be run without corefonts or font-support, especially when useflag truetype is disabled, so the dependency to corefonts is unnecessary, remove it! emerge -tpvuDN world These are the packages that would be merged, in reverse order: Calculating world dependencies... done! [ebuild U ] media-gfx/imagemagick-6.2.9.5 [6.2.8.0] USE="bzip2 jpeg perl png tiff xml zlib -X -doc -fpx -graphviz -gs -jbig -jpeg2k -lcms -mpeg -nocxx -truetype -wmf" 5,252 kB [ebuild N ] media-fonts/corefonts-1-r2 USE="-X" 3,842 kB [ebuild N ] media-libs/fontconfig-2.3.2-r1 USE="-doc" 941 kB [ebuild N ] media-libs/freetype-2.1.10-r2 USE="zlib -bindist -doc"
What happens when you run "convert label:abcde test.gif" on an imagemagick install that was emerged with out truetype enabled? If imagemagick simply does not support labels w/o true type or if it successfully creates the image (does not display an error like in the bug report), then it would seem that the best choice is to have imagemagick depend on corefonts if and only if truetype is enabled. If there is still an error generated, it would see that there really is a dependancy.
I'd make upstream just look for Sans using fontconfig...
It looks like this has already slipped into stable, but to stick my opinion in. From the page: http://imagemagick.org/script/advanced-unix-installation.php --without-x don't use the X Window System. By default, ImageMagick uses the X11 delegate libraries if they are available. When --without-x is specified, use of X11 is disabled. The display, animate, and import sub-commands are not included. The remaining sub-commands have reduced functionality such as no access to X11 fonts (consider using Postscript or TrueType fonts instead) I think that the ebuild should prefer Postscript fonts (media-fonts/gnu-gs-fonts) to Microsoft fonts in this situation.
*** Bug 147577 has been marked as a duplicate of this bug. ***
*** Bug 148089 has been marked as a duplicate of this bug. ***
I'd remove the dep and tell people to symlink the font they like or patch it to use fontconfig and use Sans.
*** Bug 153179 has been marked as a duplicate of this bug. ***
*** Bug 155436 has been marked as a duplicate of this bug. ***
Imagemagick does not need the dependency on corefonts, it is possible to configure imagemagick --without-fontconfig --without-freetype. I did a test compile from the source. Please add a useflag for the --without-fontconfig option.
post a patch showing what you mean
From the original bug report (and the documentation), clearly ImageMagick does NOT require corefonts with the X USE FLAG enabled. At a minimum the ebuild should test for that case.
Created attachment 102804 [details] ebuild compiles without: truetype, corefonts, fontconfig... Here is an ebuild which compiles fine without corefonts, without truetype. In this case, the configure script of imagemagick will do it's job and look for corefonts. If you compile imagemagick without fonts, then some commands won't be available. The ebuild is just to show, that you do not need fonts for imagemagick. I am working on an ebuild with a useflag corefonts which will add dependency to corefonts if the useflag is set. The two lines: --with-gs-font-dir=/usr/share/fonts/default/ghostscript \ --with-windows-font-dir=/usr/share/fonts/corefonts \ in the econf part will only be needed if truetype or corefont is set. I think it is better to make corefonts like truetype as an option since it is not required for imagemagick.
i wasnt kidding when i said post a *patch* regardless, i dont really see how those changes are any better than what we have currently
@SpanKY If I would have known to do it better I would have done it already, so I am sorry.
@SpanKY You force every installation of imagemagick to use corefonts and fontconfig, but since upstream leaves this as an option, gentoo should leave it as an option to the user to use fonts or not.
Comment on attachment 102804 [details] ebuild compiles without: truetype, corefonts, fontconfig... given the option of having all the features work correctly for everyone or have some features not work at all, i'm obviously going to choose the former either post a properly flexible patch or the current situation will remain unchanged
Created attachment 102810 [details, diff] patch to imagemagick-6.3.0.5.ebuild adding useflag corefonts This is my first patch I wrote. It adds a useflag "corefonts" which makes it optional to install. I am not sure about the two directories within the ifstatement if both are needed for truetype or both are needed for corefonts.
Created attachment 102828 [details, diff] only require corefonts with no X USE FLAG Probably not the right way to do this, but I think it would get rid of about ninety percent of the squawking.
(In reply to comment #22) > Created an attachment (id=102828) [edit] > only require corefonts with no X USE FLAG > > Probably not the right way to do this, but I think it > would get rid of about ninety percent of the squawking. > Why do you wanna force imagemagick to be built with corefonts, if you are running a headless system -X? I need imagemagick for the server only with no fonts and no gui, imagemagick is used with coppermine and so there is no font support needed at all. Usually, the configure script is looking for dependencies and useflags make it easier to set a dependency by the user. Forcing the user to use a dependency which is not necessary is not the right way and it would break gentoo's way of use: "leave it to the user".
(In reply to comment #23) > (In reply to comment #22) > Why do you wanna force imagemagick to be built with corefonts, > if you are running a headless system -X? I agree with you, but right now the ebuild forces EVERYONE to use corefonts - something that affects FAR more people. I don't like the idea of adding use flags for individual packages like fonts. I would suggest a "nofonts" use flag instead (which will still accomplish what you want, but require a proactive configuration decision on your part).
(In reply to comment #24) > > I don't like the idea of adding use flags for individual packages > like fonts. I would suggest a "nofonts" use flag instead (which > will still accomplish what you want, but require a proactive > configuration decision on your part). > Good point, every solution which lets the option to the user whether to use imagemagick with fonts or not is good.
(In reply to comment #24) > I don't like the idea of adding use flags for individual packages > like fonts. I would suggest a "nofonts" use flag instead (which > will still accomplish what you want, but require a proactive > configuration decision on your part). The devs don't like no-anything type USE flags, and try to only use them if there'd normally be DIRE results for turning the flag on (nocxx for example, will kill python and thus portage, I am told). Thus, "nofonts" isn't likely, but something like "fonts" might be.
Reopening as this is significant and I'm happy to help fixing it. The base of the issue seems to be that the ebuild unconditionally uses --with-windows-font-dir=/usr/share/fonts/corefonts and at least in terms of that, adding the unconditional dep on corefonts was correct. However, imagemagick can operate fine without these "windows fonts", this dependency introduces some other unwanted stuff, and the licensing for corefonts sucks -- this really needs to be made optional. Unsetting X/truetype/other USE flags does not help here -- the convert command given earlier ("convert label:abcde test.gif") is still able to operate correctly even without X and truetype support provided that it can find a font. If no windows font dir is specified (i.e. "--with-windows-font-dir=") then the above command works fine regardless of corefonts' presence, this is because it then uses ghostscript to render the text. Here are 3 possible solutions: 1. Always specify no windows font dir and let it use ghostscript. This isn't a great idea as it probably causes some other functionality to suffer and also removes the option of using windows fonts. 2. Extend the meaning of USE=truetype to cover windows font stuff. I think this is an acceptable extension because after all these windows fonts are actually just truetype fonts. In this case the corefonts dep would be conditional based on USE=truetype, and windows font path would either be "" or "/usr/share/fonts/corefonts" again depending on the USE flag. 3. Add a fallback in the imagemagick code to fall back onto ghostscript if font rendering with windows fonts fails. This isn't as easy as it sounds due to upstream code mess. Their code really only wants to work with one font engine and in the TTF case it really wants to work with a single flat directory. In the long term hopefully this will improve (e.g. to use fontconfig). I prefer #2 from the list above, patch coming up shortly.
Created attachment 108683 [details, diff] Make windows font support conditional based on USE=truetype
In regards to comment 27, I much prefer option 2) as you then get the desired basic functionality out of the box, but can go back and add more fonts in (or change the fonts) if you find the render is not the font you want. The most important reason to me for opening this in the first place was that a basic function used in the imagemagick FAQ to assure your installation was working correctly, was failing out of the box on Gentoo. Instantiating Daniel Drake's patch I believe solves that original issue in a more satisfactory way that simple always requiring corefonts (at least now that I understand why some one would want to not have it).
Mike asks: <@vapier> if you have imagemagick on a server without X or corefonts, how can the label: command work Using --without-ttf (and all other flags except the ones mentioned) turned off: If configured with "--with-windows-font-dir=/usr/share/fonts/corefonts" it fails: convert: unable to read font `/usr/share/fonts/corefonts/arial.ttf'. convert: missing an image filename `test.gif'. If configured with "--with-windows-font-dir= --with-gs-font-dir=/usr/share/fonts/default/ghostscript --without-gslib" then it works. strace shows it open()ing files such as /usr/share/fonts/default/ghostscript/n019003l.afm This also works after unmerging ghostscript-gpl but fails when gnu-gs-fonts-std is also unmerged. So, I guess the answer to the question is: it uses ghostscript fonts (but doesn't require the gs libs to do so)
Should use this instead: $(use_with truetype windows-font-dir /usr/share/fonts/corefonts) will test and commit tomorrow
Doesn't work. USE=-truetype causes --without-windows-font-dir rather than --with-windows-font-dir= Mike, should upstream Makefile be fixed or should we handle this at the ebuild level something like my earlier patch?
Would a "virtual/truetype" package solve this problem?
no
(In reply to comment #34) > no > Here's a better question: How can including the word "corefonts" in the imagemagick ebuild be reasonable? Imagemagick has absolutely nothing to do with Microsoft's fonts. Requiring such a dependency is absurd. I'm not trolling. Please create a suitable workaround, or suggest to others an alternative method you consider acceptable, and we'll do it.
This has already been explained above, but here it is again: ImageMagick is SPECIFICALLY written to include support for WINDOWS FONTS. It is after all both a Windows and Linux app. corefonts is the only provider of windows fonts in Portage. Ripping out support for Windows fonts in imagemagick would be removing functionality which is not something we commonly do at the ebuild level. The correct solution is to make the dependency conditional since it can ALSO work with ghostscript fonts. If you look at the last few comments you will see that work is underway to make that so.
(In reply to comment #35) > > Imagemagick has absolutely nothing to do with Microsoft's fonts. > [Please suggest] an alternative method you consider acceptable, > and we'll do it. FWIW, Gentoo actually provides (at least) TWO workarounds. You can take your pick based on your needs. =8^) I'm not too happy about the dependency either, for the reasons explained below, but since they are working on it and there are workarounds in the meantime, it's not /so/ bad. Simply stick media-fonts/corefonts-99 or some such in your package.provided file. That's what I did here, since I can't agree to the corefonts EULA, and since those may be legal/enforceable here in the US, it's therefore of questionable legality for me to merge the corefonts package. For more information on package.provided, see the portage (5) manpage. As mentioned "up bug", that does break some of the text functionality. However, I'm not likely to use that anyway as imagemagick is just an image processing dependency of a couple things I have merged and I'm not likely to be doing fancy things with text in them and thus in imagemagick. For those that need the text functionality, there's the overlay method. Stick the ebuild in your overlay and edit it to point at the ghostscript fonts or whatever, instead of depending on corefonts. Then redigest and merge as usual. See, it's not /so/ bad, since there are already workarounds available. One just needs to learn to use the tools Gentoo already provides. =8^)
Created attachment 109537 [details] imagemagick-6.3.0.5.ebuild updated ebuild
Created attachment 109550 [details] imagemagick-6.3.0.5.ebuild updated ebuild
Created attachment 109552 [details, diff] files/imagemagick-6.3.0.5-configure-windows-fonts.patch configure fix
in portage
*** Bug 186367 has been marked as a duplicate of this bug. ***
*** Bug 299840 has been marked as a duplicate of this bug. ***
