Bug 227761 - print/freetype2: Fonts aren't correctly rendered with 2.9
Summary: print/freetype2: Fonts aren't correctly rendered with 2.9
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-gnome (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-25 11:16 UTC by Pascal Christen
Modified: 2018-12-27 14:35 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (gnome)
i.dani: maintainer-feedback? (bapt)


Attachments
Patch for print/freetype2 (since 468892 revision) (1.59 KB, patch)
2018-05-03 01:34 UTC, lightside
no flags Details | Diff
Testing environment for freetype2, based on git bisect (114.69 KB, application/x-bzip)
2018-05-03 02:09 UTC, lightside
no flags Details
Testing environment for freetype2, based on git bisect (3.08 KB, application/x-bzip)
2018-05-04 02:05 UTC, lightside
no flags Details
The freetype2 debug output for ImageMagick convert program (36.58 KB, application/x-bzip)
2018-05-04 03:33 UTC, lightside
no flags Details
The freetype2 debug output for ImageMagick convert program (48.75 KB, application/x-bzip)
2018-05-05 19:30 UTC, lightside
no flags Details
Testing environment for freetype2, based on git bisect (3.09 KB, application/x-bzip)
2018-05-05 20:57 UTC, lightside
no flags Details
Testing environment for freetype2, based on git bisect (3.09 KB, application/x-bzip)
2018-05-07 23:42 UTC, lightside
no flags Details
The freetype2 debug output for ImageMagick convert program (158.42 KB, application/x-bzip)
2018-05-12 07:58 UTC, lightside
no flags Details
Testing environment for freetype2, based on git bisect (3.09 KB, application/x-bzip)
2018-06-12 16:35 UTC, lightside
no flags Details
The freetype2 debug output (Ghostscript 9.23) (123.55 KB, application/x-bzip)
2018-06-12 17:47 UTC, lightside
no flags Details
How the font looks like (101.21 KB, image/png)
2018-08-16 11:05 UTC, Pascal Christen
no flags Details
pdf test file (39.12 KB, application/pdf)
2018-08-17 08:56 UTC, Pascal Christen
no flags Details
The freetype2 debug output for test_empty.pdf (Ghostscript 9.23) (13.92 KB, application/x-bzip)
2018-08-18 01:30 UTC, lightside
no flags Details
The print/ghostscript9-agpl-base for test (4ade82d) (3.31 KB, application/x-bzip)
2018-08-20 02:06 UTC, lightside
no flags Details
Proposed patch for print/ghostscript9-agpl-base (since 473400 revision) (1.42 KB, patch)
2018-08-20 20:09 UTC, lightside
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal Christen 2018-04-25 11:16:45 UTC
Hi

Since the update to freetype2 2.9 (from 2.8.1) we're not able to render the embedded pdf fonts correctly to a jpg. We're using imagemagick for rendering but even tried ghostscript with the same result.

The developers think it's not a fault of freetype because they can't reproduce it. Could it be a problem related to the FreeBSD port?

Here's the link to the bugtracking of freetype (including a pdf for testing):
https://savannah.nongnu.org/bugs/?53739#postcomment
Comment 1 Dani I. 2018-05-02 08:59:07 UTC
Any news on this? :)
Comment 2 Baptiste Daroussin freebsd_committer freebsd_triage 2018-05-02 09:10:43 UTC
I can reproduce for sure, but I am not sure how to debug that :(
Comment 3 lightside 2018-05-03 01:32:44 UTC
Hello.

(In reply to Baptiste Daroussin from comment #2)
> I can reproduce for sure, but I am not sure how to debug that :(
I think, possible to compare checksums for generated image with using (expected) checksum value from FreeType 2.8 version (built with using (almost) the same options) to identify related change(s) (and/or Git commit):
% make clean build
% cd work/*
% env LD_PRELOAD=./objs/.libs/libfreetype.so convert -append path/to/file.pdf image.jpg
% sha256 -q image.jpg
<..>

I slightly modified testing environment for freetype2, which I introduced in bug 219608 comment #27.
The (automated) git bisect have found following commit:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=75cb071b3fbfa2315c5d458fee2bb465a14568ae
-8<--
# bad: [86bc8a95056c97a810986434a3f268cbe67f2902] * Version 2.9.1 released. =========================
# good: [a12a34451a99cbbcad55d466940fd445171927fd] * Version 2.8 released. =======================
git bisect start 'VER-2-9-1' 'VER-2-8' '--'
# bad: [2f0e11406890cbd15d86f8e75ab6ab4da8898af4] Add tracing for hints.
git bisect bad 2f0e11406890cbd15d86f8e75ab6ab4da8898af4
# bad: [f53ccf6f8f3d1c5c717b0edd0529ef677c981f22] Minor comment fix.
git bisect bad f53ccf6f8f3d1c5c717b0edd0529ef677c981f22
# good: [79e3789f81e14266578e71196ce71ecf5381d142] * src/winfonts/winfnt.c (FNT_Face_Init): Don't set active encoding.
git bisect good 79e3789f81e14266578e71196ce71ecf5381d142
# bad: [229a5535b53b308a8edda894fe112517c6d03b00] CHANGES: Add information on global metrics rounding.
git bisect bad 229a5535b53b308a8edda894fe112517c6d03b00
# bad: [2e7bb5e825880301e762f41fd0efa2aa18a4421f] * src/cff/cffparse.c (do_fixed): Fix typo.
git bisect bad 2e7bb5e825880301e762f41fd0efa2aa18a4421f
# good: [c8829e4bc18c99b8cc0f747216c2191ec669e11a] Fix pkg-config in freetype-config for cross-compiling (#51274).
git bisect good c8829e4bc18c99b8cc0f747216c2191ec669e11a
# bad: [298e2ea5a6c2e3264f8abaa8b1d2371fb4c77f4d] [cff, truetype] Integer overflows.
git bisect bad 298e2ea5a6c2e3264f8abaa8b1d2371fb4c77f4d
# bad: [75cb071b3fbfa2315c5d458fee2bb465a14568ae] [sfnt] Synthesize a Unicode charmap if one is missing.
git bisect bad 75cb071b3fbfa2315c5d458fee2bb465a14568ae
# good: [390048fa468dfee06f722da6b8ca1b79022480d6] Remove deprecated comment.
git bisect good 390048fa468dfee06f722da6b8ca1b79022480d6
# first bad commit: [75cb071b3fbfa2315c5d458fee2bb465a14568ae] [sfnt] Synthesize a Unicode charmap if one is missing.
-->8-

The changes in 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit mentions about FT_CONFIG_OPTION_POSTSCRIPT_NAMES define:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/config/ftoption.h?h=VER-2-9-1#n290
-8<--
  /*************************************************************************/
  /*                                                                       */
  /* Glyph Postscript Names handling                                       */
  /*                                                                       */
  /*   By default, FreeType 2 is compiled with the `psnames' module.  This */
  /*   module is in charge of converting a glyph name string into a        */
  /*   Unicode value, or return a Macintosh standard glyph name for the    */
  /*   use with the TrueType `post' table.                                 */
  /*                                                                       */
  /*   Undefine this macro if you do not want `psnames' compiled in your   */
  /*   build of FreeType.  This has the following effects:                 */
  /*                                                                       */
  /*   - The TrueType driver will provide its own set of glyph names,      */
  /*     if you build it to support postscript names in the TrueType       */
  /*     `post' table, but will not synthesize a missing Unicode charmap.  */
  /*                                                                       */
  /*   - The Type 1 driver will not be able to synthesize a Unicode        */
  /*     charmap out of the glyphs found in the fonts.                     */
  /*                                                                       */
  /*   You would normally undefine this configuration macro when building  */
  /*   a version of FreeType that doesn't contain a Type 1 or CFF driver.  */
  /*                                                                       */
#define FT_CONFIG_OPTION_POSTSCRIPT_NAMES
-->8-

I found, if comment/remove FT_CONFIG_OPTION_POSTSCRIPT_NAMES define in include/freetype/config/ftoption.h file, then this may fix issue for this PR. Maybe, there are other solutions, of course.
Comment 4 lightside 2018-05-03 01:34:51 UTC
Created attachment 193012 [details]
Patch for print/freetype2 (since 468892 revision)

(In reply to comment #3)
Attached proposed patch with following changes:
- Bump PORTREVISION
- Add GPN option for "Glyph Postscript Names handling"

The fix for this PR is disabled GPN option, in this case. Please test.
Comment 5 lightside 2018-05-03 02:09:43 UTC
Created attachment 193013 [details]
Testing environment for freetype2, based on git bisect

(In reply to comment #3)
> I slightly modified testing environment for freetype2, which I introduced in
> bug 219608 comment #27.
Also attached archive with modified testing environment, if somebody interested.

How to use:
1. Extract (downloaded) attached archive to new directory:
% mkdir bisect
% tar -xf freetype2_bisect.tar.bz2 -C bisect
2. Change destination to new directory and clone freetype2 git repository in it:
% cd bisect
% git clone https://git.savannah.gnu.org/git/freetype/freetype2.git
3. Configure needed options in test.sh file, e.g. OPTION_SUBPIXEL_HINTING, OPTION_LONG_PCF_NAMES, OPTION_SUBPIXEL_RENDERING, which will be used, when available.
4. Configure expected_checksum variable in test.sh file:
4.1 Checkout VER-2-8:
% cd freetype2
% git checkout VER-2-8
4.2 And run test.sh in related directory:
% ../test.sh
If there were no errors, this gives some sha256 checksum, which need to specify for expected_checksum variable in test.sh file:
expected_checksum="1370a12f43a024354c77b206c6af83a9ae330ca8d31361ceea2895a23458a9ec"
4.3. (Optional) Checkout previous commit, e.g. master:
% git checkout master
5. Configure git bisect and run it:
% git bisect start VER-2-9-1 VER-2-8 --
% git bisect run ../test.sh
6. At the end this may show found commit, which possible to check with `git bisect visualize` and `git bisect log` commands.
7. Finish bisection search and go back to (previous) commit:
% git bisect reset
Comment 6 lightside 2018-05-04 02:05:59 UTC
Created attachment 193036 [details]
Testing environment for freetype2, based on git bisect

(In reply to Baptiste Daroussin from comment #2)
> I can reproduce for sure, but I am not sure how to debug that :(
I think, also possible to enable some debugging features in a FreeType 2 builds (e.g. selected DEBUG option for print/freetype2 port):
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/DEBUG?h=VER-2-9-1#n1
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/config/ftoption.h?h=VER-2-9-1#n398

After build possible to use FT2_DEBUG (and/or other) environment variable(s) in conjunction with test program. For example:
% env FT2_DEBUG="any:5" LD_PRELOAD=./objs/.libs/libfreetype.so sh -c "convert -append path/to/file.pdf image.jpg 2>&1"

Attached new archive with testing environment:
- Added -d option for "git clean" command to also remove created directories during build, e.g. ./objs/.libs
- Added help, clean, build, test options for test.sh script
- Added some debugging settings
- Removed anonyme_visitenkarte.pdf file, which possible to download/extract from previous attachment #193013 [details]:
% fetch -o - "https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193013" | tar -xf - --include anonyme_visitenkarte.pdf
% sha256 anonyme_visitenkarte.pdf 
SHA256 (anonyme_visitenkarte.pdf) = 949b114d3e2cf21fc7f97ade1491c73c292fee04525c2cf551ab05543901d6ae
Comment 7 lightside 2018-05-04 03:33:27 UTC
Created attachment 193039 [details]
The freetype2 debug output for ImageMagick convert program

(In reply to comment #6)
> I think, also possible to enable some debugging features
> in a FreeType 2 builds
Possible to compare debugging outputs for previous and found 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit.
-8<--
% fetch -o freetype2_bisect.tar.bz2 "https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193036"
<..>
% sha256 freetype2_bisect.tar.bz2 
SHA256 (freetype2_bisect.tar.bz2) = f521934f01a2fdbaa5a9b129ea65c70dc510f82310fb23deba92df71da7528af
% mkdir bisect
% tar -xf freetype2_bisect.tar.bz2 -C bisect
% cd bisect
% fetch -o - "https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193013" | tar -xf - --include anonyme_visitenkarte.pdf
<..>
% sha256 anonyme_visitenkarte.pdf
SHA256 (anonyme_visitenkarte.pdf) = 949b114d3e2cf21fc7f97ade1491c73c292fee04525c2cf551ab05543901d6ae
% git clone https://git.savannah.gnu.org/git/freetype/freetype2.git
<..>
% cd freetype2
% git checkout 75cb071b3fbfa2315c5d458fee2bb465a14568ae^
<..>
HEAD is now at 390048fa4 Remove deprecated comment.
% ../test.sh build
<..>
% convert --version | head -1
Version: ImageMagick 6.9.9-28 Q16 amd64 2018-04-29 http://www.imagemagick.org
% mkdir -p ../output/prev
% git show -s --format="# %s%n# https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=%H" 75cb071b3fbfa2315c5d458fee2bb465a14568ae^ > ../output/prev/commit.txt
% seq 5 | xargs -I {} -L 1 env FT2_DEBUG="any:{}" LD_PRELOAD=./objs/.libs/libfreetype.so sh -c "convert -append ../anonyme_visitenkarte.pdf image.jpg 2>&1 | tee ../output/prev/{}.txt"
<..>
% ../test.sh clean
% git checkout 75cb071b3fbfa2315c5d458fee2bb465a14568ae
Previous HEAD position was 390048fa4 Remove deprecated comment.
HEAD is now at 75cb071b3 [sfnt] Synthesize a Unicode charmap if one is missing.
% ../test.sh build
<..>
% mkdir -p ../output/found
% git show -s --format="# %s%n# https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=%H" 75cb071b3fbfa2315c5d458fee2bb465a14568ae > ../output/found/commit.txt
% seq 5 | xargs -I {} -L 1 env FT2_DEBUG="any:{}" LD_PRELOAD=./objs/.libs/libfreetype.so sh -c "convert -append ../anonyme_visitenkarte.pdf image.jpg 2>&1 | tee ../output/found/{}.txt"
<..>
% ../test.sh clean
% git checkout master
<..>
-->8-

Attached archive with output results for various debugging levels (from 1 to 5), which possible to compare with using diff (or other) command:
% diff -ruNd prev found > result.diff

The question is how to interpret such results and find related changes in the source code.
The first guess was about FT_CONFIG_OPTION_POSTSCRIPT_NAMES define (see comment #3).
Comment 8 Pascal Christen 2018-05-04 07:35:21 UTC
(In reply to lightside from comment #4)

Thank you for debugging. This patch works for me. Any impact when applying this patch?
Comment 9 lightside 2018-05-04 10:02:30 UTC
(In reply to Pascal Christen from comment #8)
> Any impact when applying this patch?
The disabled GPN port's option may disable FT_CONFIG_OPTION_POSTSCRIPT_NAMES define in include/freetype/config/ftoption.h file:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/include/freetype/config/ftoption.h?h=VER-2-9-1#n290
This may disable psnames module, which "is in charge of converting a glyph name string into a Unicode value, or return a Macintosh standard glyph name for the use with the TrueType `post' table" (from description of ftoption.h file):
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/modules.cfg?h=VER-2-9-1#n154
-8<--
# Support for PostScript glyph names.
#
# This module can be controlled in ftconfig.h
# (FT_CONFIG_OPTION_POSTSCRIPT_NAMES).
AUX_MODULES += psnames
-->8-
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/psnames/psmodule.c?h=VER-2-9-1#n47
etc.

If you need to just use ImageMagick convert (or other) program, then, as intermediate solution, I may suggest to build libfreetype.so* without FT_CONFIG_OPTION_POSTSCRIPT_NAMES define in include/freetype/config/ftoption.h file and use LD_PRELOAD environment variable for needed program (while ABI is compatible):
% env LD_PRELOAD=path/to/libfreetype.so convert file.pdf image.jpg

For example, apply patch for print/freetype2 in attachment #193012 [details] (as you already did, e.g. in some user's directory):
% svn co -r 468892 https://svn.FreeBSD.org/ports/head/print/freetype2
% fetch -o freetype2.diff "https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193012"
<..>
% cd freetype2
% svn patch ../freetype2.diff

Then build without GPN option and copy libfreetype.* files to another location:
% make WITHOUT=GPN stage
<..>
% ls work/stage/usr/local/lib/libfreetype*
work/stage/usr/local/lib/libfreetype.a		work/stage/usr/local/lib/libfreetype.so.6
work/stage/usr/local/lib/libfreetype.so		work/stage/usr/local/lib/libfreetype.so.6.16.1
% mkdir ../freetype2_libs
% cp -fp work/stage/usr/local/lib/libfreetype* ../freetype2_libs
% make clean
<..>

The ../freetype2_libs will contain needed libfreetype.so library (and related files), in this case:
% cd ..
% fetch -o - "https://bugs.freebsd.org/bugzilla/attachment.cgi?id=193013" | tar -xf - --include anonyme_visitenkarte.pdf
% env LD_PRELOAD=./freetype2_libs/libfreetype.so convert -append anonyme_visitenkarte.pdf image.jpg

As for overall issue, the affected commit is 75cb071b3fbfa2315c5d458fee2bb465a14568ae (according to git bisect):
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=75cb071b3fbfa2315c5d458fee2bb465a14568ae
Comment 10 lightside 2018-05-05 19:30:45 UTC
Created attachment 193066 [details]
The freetype2 debug output for ImageMagick convert program

Created debugging output for 2b3e0ef6c095cf6ea920e95fc9826dc39694162a commit:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=2b3e0ef6c095cf6ea920e95fc9826dc39694162a
-8<--
% echo $FREETYPE_PROPERTIES
FREETYPE_PROPERTIES: Undefined variable.
% pkg info fontconfig | grep -e ^Version -e ^Options -e ": on" -e ": off"
Version        : 2.12.6,1
Options        :
	DOCS           : on
	HINTING_FULL   : off
	HINTING_MEDIUM : off
	HINTING_NONE   : off
	HINTING_SLIGHT : on
	NO_BITMAPS     : off
% cat ${HOME}/.config/fontconfig/fonts.conf
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
	<match target="font">
		<edit mode="assign" name="rgba">
			<const>rgb</const>
		</edit>
	</match>
	<match target="font">
		<edit mode="assign" name="hinting">
			<bool>true</bool>
		</edit>
	</match>
	<match target="font">
		<edit mode="assign" name="hintstyle">
			<const>hintslight</const>
		</edit>
	</match>
	<match target="font">
		<edit mode="assign" name="antialias">
			<bool>true</bool>
		</edit>
	</match>
	<match target="font">
		<edit mode="assign" name="lcdfilter">
		  <const>lcddefault</const>
		</edit>
	</match>
	<match target="pattern">
		<test qual="any" name="size" compare="less_eq">
			<int>12</int>
		</test>
		<edit name="antialias" mode="assign">
			<bool>false</bool>
		</edit>
	</match>
</fontconfig>
% git describe
VER-2-9-1-3-g2b3e0ef6c
% setenv OUTPUT `git describe`
% echo $OUTPUT
VER-2-9-1-3-g2b3e0ef6c
% ../test.sh build
<..>
% ../test.sh test
81d778f88b71adbd4d99f9b405d53779042d02043bacd8f94f76d690e6ec1600
not match
% mkdir -p ../output/$OUTPUT
% git show -s --format="%s%nhttps://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=%H"
Support symbol visibility features of Sun / Oracle C compilers. Reported by Kiyoshi Kanazawa: https://lists.gnu.org/archive/html/freetype-devel/2018-05/msg00008.html Thanks to the suggestions by Alexei and Alan Coopersmith.
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=2b3e0ef6c095cf6ea920e95fc9826dc39694162a
% git show -s --format="# %s%n# https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=%H" > ../output/$OUTPUT/commit.txt
% seq 5 | xargs -I {} -L 1 env FT2_DEBUG="any:{}" LD_PRELOAD=./objs/.libs/libfreetype.so sh -c "convert -append ../anonyme_visitenkarte.pdf image.jpg 2>&1 | tee ../output/$OUTPUT/{}.txt"
<..>
% ../test.sh clean
-->8-

Added VER-2-9-1-3-g2b3e0ef6c directory to debug_output.tar.bz2 archive from attachment #193039 [details].

Some comments to "Sat 05 May 2018 06:54:13 AM UTC" on https://savannah.nongnu.org/bugs/?53739#comment5:
Need to note, that so called testing environment (attachment #193036 [details]) was created on FreeBSD (10.3, 10.4) and tested for /bin/sh in FreeBSD base:
https://www.freebsd.org/cgi/man.cgi?query=sh&apropos=0&sektion=0&manpath=FreeBSD+10.4-RELEASE&arch=default&format=html
% sha256 /bin/sh
SHA256 (/bin/sh) = ea533f9919285db456d647dade105846af9ba6d2638dee1f7ffe43c51460fef3

Also, I didn't propose to comment FT_CONFIG_OPTION_POSTSCRIPT_NAMES define in include/freetype/config/ftoption.h file as a solution for upstream. This is just a so called "workaround" (or an intermediate solution, because the disabled GPN option is not default (i.e. OPTIONS_DEFAULT+=GPN in attachment #193012 [details]) for print/freetype2 port), based on changes in 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=75cb071b3fbfa2315c5d458fee2bb465a14568ae

I just showed some examples about how to possibly debug print/freetype2 port on FreeBSD for this PR. Also shared some testing environment (and results), which I used for git bisect run, and asked about whether (disabled) FT_CONFIG_OPTION_POSTSCRIPT_NAMES define affects this issue for PR's reporter(s).

Thanks for attention.
Comment 11 lightside 2018-05-05 20:57:21 UTC
Created attachment 193068 [details]
Testing environment for freetype2, based on git bisect

(In reply to comment #11)
> Some comments to "Sat 05 May 2018 06:54:13 AM UTC" on
> https://savannah.nongnu.org/bugs/?53739#comment5
Converted some names of functions with hyphen(s) to _ variants in test.sh script, just in case.
Comment 12 lightside 2018-05-07 23:42:24 UTC
Created attachment 193168 [details]
Testing environment for freetype2, based on git bisect

Changed "WITHOUT_DEBUG_FILES=yes	WITHOUT_KERNEL_SYMBOLS=yes" to "MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no" in test.sh script, after ports r469338 changes for Mk/bsd.port.mk, just in case. In this regard, the patch/configure/build stages in test.sh script was created on base of what is used in FreeBSD ports (on some period of time). Some environment variables maybe not used for actual freetype2 configure/build process, but as is.
Comment 13 lightside 2018-05-12 07:58:20 UTC
Created attachment 193316 [details]
The freetype2 debug output for ImageMagick convert program

I found, that installed Ghostscript 9.16 version is possible cause of this issue:
% pkg info -d ImageMagick | grep ghostscript
	ghostscript9-agpl-x11-9.16_2
	ghostscript9-agpl-base-9.16_5
% pkg info -xo ghostscript ImageMagick
ghostscript9-agpl-base-9.16_5  print/ghostscript9-agpl-base
ghostscript9-agpl-x11-9.16_2   print/ghostscript9-agpl-x11
ImageMagick-6.9.9.28,1         graphics/ImageMagick

https://www.freshports.org/print/ghostscript9-agpl-base
https://www.freshports.org/print/ghostscript9-agpl-x11

As I understood, there is a usage of "agpl" type of ghostscript's ports by default:
https://github.com/freebsd/freebsd-ports/blob/518ef677fadda04fc579509938a445639e1535f9/Mk/bsd.default-versions.mk#L45-L46
-8<--
# Possible values: 7, 8, 9, agpl
GHOSTSCRIPT_DEFAULT?= agpl
-->8-

https://github.com/freebsd/freebsd-ports/blob/7c530a068083f634f8df021dd4642dcdc7c2f310/Mk/Uses/ghostscript.mk#L32-L35
-8<--
# allowed versions
# When adding a version, please keep the comment in
# Mk/bsd.default-versions.mk in sync.
_GS_VERSION= 7 8 9 agpl
-->8-

https://github.com/freebsd/freebsd-ports/blob/7c530a068083f634f8df021dd4642dcdc7c2f310/Mk/Uses/ghostscript.mk#L43-L45
-8<--
.if ${GHOSTSCRIPT_DEFAULT:N[789]:Nagpl}
IGNORE?=	Invalid GHOSTSCRIPT_DEFAULT value: ${GHOSTSCRIPT_DEFAULT}, please select one of ${_GS_VERSION}
.endif
-->8-

There is no issue, if using Ghostscript 9.06 version, by adding "DEFAULT_VERSIONS+=ghostscript=9" (without quotes) to /etc/make.conf file and rebuild of graphics/ImageMagick port (after removal of currently installed ghostscript packages, e.g. with using following command: `pkg delete -fx ghostscript ImageMagick`):
% pkg info -xo ghostscript ImageMagick
ghostscript9-base-9.06_13      print/ghostscript9-base
ghostscript9-x11-9.06_12       print/ghostscript9-x11
ImageMagick-6.9.9.28,1         graphics/ImageMagick

https://www.freshports.org/print/ghostscript9-base
https://www.freshports.org/print/ghostscript9-x11

Added new freetype2 debug output (in "9" directory of archive), when using Ghostscript 9.06 version. For the same commits:
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=390048fa468dfee06f722da6b8ca1b79022480d6
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=75cb071b3fbfa2315c5d458fee2bb465a14568ae
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=2b3e0ef6c095cf6ea920e95fc9826dc39694162a

Some differences from previous attachment #193066 [details]:
- Moved "prev", "found" and "VER-2-9-1-3-g2b3e0ef6c" directories to "agpl" directory
- Added generated image.jpg files to corresponding directories
- Added packages.txt file(s) to "9" and "agpl" directories, which contains information about `pkg info -xo ghostscript ImageMagick` output

Werner Lemberg said (in https://savannah.nongnu.org/bugs/?53739#comment3), that "Using gs 9.23 the PDF gets displayed fine". As I understood, the 9.23 is currently latest Ghostscript version:
https://www.ghostscript.com/News.html
https://www.ghostscript.com/Ghostscript_9.23.html

Probably, another possible fix (in addition to usage of other GHOSTSCRIPT_DEFAULT value, except "agpl") is to update print/ghostscript9-agpl-base and print/ghostscript9-agpl-x11 ports to 9.23 (or other) version, which may have fix(es) for this issue.
Comment 14 lightside 2018-05-12 08:10:06 UTC
Comment on attachment 193012 [details]
Patch for print/freetype2 (since 468892 revision)

Renamed description of attachment #193012 [details].

The patch was used to test issue in this PR, when using disabled GPN port's option (or as a "workaround") and installed print/ghostscript9-agpl-base and print/ghostscript9-agpl-x11 ports for 9.16 version.
Comment 15 lightside 2018-06-12 16:34:38 UTC
(In reply to comment #13)
The print/ghostscript9-agpl-base and print/ghostscript9-agpl-x11 ports was updated to 9.23 version in ports r472239 by tijl@.

Looks like, this fixed issue for this PR. Please test.
Comment 16 lightside 2018-06-12 16:35:39 UTC
Created attachment 194200 [details]
Testing environment for freetype2, based on git bisect

(In reply to comment #15)
The git bisect (e.g. expected_checksum="5c7f74eef068eaf2f3db0cb24a1fa0914dc4654e28b08b15ee1a1add8a0413de" in test.sh, based on sha256 checksum for generated image.jpg from VER-2-8 tag) may find the same 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit. But possible to read characters from generated image.jpg, when using Ghostscript 9.23 (and 9.06).

Updated value for expected_checksum variable in test.sh script from attachment #193316 [details], just in case.
Comment 17 lightside 2018-06-12 17:14:49 UTC
I wanted to attach new freetype2 debug output (in "agpl/9.23" directory of archive), when using Ghostscript 9.23 version. For the same commits (see comment #13), including (for "agpl/9.23" directory only):
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=eaa5a42a12ce1f1fe005109da6841e411babe826

But somehow this wasn't possible, because of long wait time after clicking on "Submit" button and nothing after that. Uploaded debug_output.tar.bz2 archive to some file hosting (for 2 months), just in case:
https://files.fm/f/2f28egew

-8<--
% sha256 debug_output.tar.bz2 
SHA256 (debug_output.tar.bz2) = 17691eb7440a86cc0063c6940e65cd98d9ac5d421f3aab82ddb61af46e7d4cff
% clamscan debug_output.tar.bz2
debug_output.tar.bz2: OK

----------- SCAN SUMMARY -----------
Known viruses: 6546039
Engine version: 0.100.0
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 14.89 MB
Data read: 0.27 MB (ratio 55.25:1)
Time: 22.735 sec (0 m 22 s)
-->8-

Some differences (based on attachment #193316 [details]):
- Moved directories and files from agpl to agpl/9.16 directory
- Added debug output for eaa5a42a12ce1f1fe005109da6841e411babe826 commit to agpl/9.16/VER-2-9-1-65-geaa5a42a1 directory
Comment 18 lightside 2018-06-12 17:18:11 UTC
(In reply to comment #17)
> - Added debug output for eaa5a42a12ce1f1fe005109da6841e411babe826 commit to
> agpl/9.16/VER-2-9-1-65-geaa5a42a1 directory
to agpl/9.23/VER-2-9-1-65-geaa5a42a1 directory, of course.
Comment 19 lightside 2018-06-12 17:47:10 UTC
Created attachment 194202 [details]
The freetype2 debug output (Ghostscript 9.23)

(In reply to comment #15)
> I wanted to attach new freetype2 debug output (in "agpl/9.23" directory of
> archive), when using Ghostscript 9.23 version.
Looks like, was possible to attach new archive with agpl-9.23 (instead of "agpl/9.23") directory only.
Probably, previous upload issue was delay related.
Comment 20 lightside 2018-06-13 09:21:27 UTC
(In reply to comment #16)
> Updated value for expected_checksum variable in test.sh script
> from attachment #193316 [details]
from attachment #193168 [details]

As about this PR, the Ghostscript v9.06 was unaffected to changes between FreeType v2.8 and v2.8.1, if compare checksums for generated image.jpg file:
-8<--
sha256 9/*/image.jpg 
SHA256 (9/VER-2-9-1-3-g2b3e0ef6c/image.jpg) = ed83b79b56765d9ea69c405134e300310cf99c96cf464500a9cc841b3321df75
SHA256 (9/found/image.jpg) = ed83b79b56765d9ea69c405134e300310cf99c96cf464500a9cc841b3321df75
SHA256 (9/prev/image.jpg) = ed83b79b56765d9ea69c405134e300310cf99c96cf464500a9cc841b3321df75
-->8-

The git bisect found the same 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit for Ghostscript v9.16 and v9.23, while they have different checksums for generated image.jpg file:
-8<--
% sha256 agpl/*/*/image.jpg
SHA256 (agpl/9.16/VER-2-9-1-3-g2b3e0ef6c/image.jpg) = 81d778f88b71adbd4d99f9b405d53779042d02043bacd8f94f76d690e6ec1600
SHA256 (agpl/9.16/found/image.jpg) = 81d778f88b71adbd4d99f9b405d53779042d02043bacd8f94f76d690e6ec1600
SHA256 (agpl/9.16/prev/image.jpg) = 1370a12f43a024354c77b206c6af83a9ae330ca8d31361ceea2895a23458a9ec
SHA256 (agpl/9.23/VER-2-9-1-3-g2b3e0ef6c/image.jpg) = d4f1f4b486b5cdb22c1f57a4c518b833ab37fb43ca1a723bb75e002e4d7de55e
SHA256 (agpl/9.23/VER-2-9-1-65-geaa5a42a1/image.jpg) = d4f1f4b486b5cdb22c1f57a4c518b833ab37fb43ca1a723bb75e002e4d7de55e
SHA256 (agpl/9.23/found/image.jpg) = d4f1f4b486b5cdb22c1f57a4c518b833ab37fb43ca1a723bb75e002e4d7de55e
SHA256 (agpl/9.23/prev/image.jpg) = 5c7f74eef068eaf2f3db0cb24a1fa0914dc4654e28b08b15ee1a1add8a0413de
-->8-

On the other hand, the Ghostscript v9.06 and v9.23 rendered the same characters (in symbolic form; while visually different (a little)) for generated image.jpg file.

Some changes between FreeType v2.8 and v2.8.1 affected Ghostscript v9.16, which probably used different algorithms (or had some issue(s)) for related parts, compared to Ghostscript v9.06.
Comment 21 Pascal Christen 2018-06-14 11:52:51 UTC
With print/ghostscript9-agpl-base 9.23 it works for me too!

Close?
Comment 22 Walter Schwarzenfeld freebsd_triage 2018-06-14 12:14:36 UTC
See Comment21. So I close here as fixed.
Comment 23 Pascal Christen 2018-08-09 14:31:31 UTC
Having the same problem again but with another pdf:

installed:
freetype2-2.9.1
ghostscript9-agpl-base-9.23_1

command:
convert -density 300 -colorspace sRGB -resize 50% -border 2 test.pdf[0] output.jpg


what kind of output do you guys need?

Image is fine when using freetype2-2.8.1
Comment 24 lightside 2018-08-10 05:37:53 UTC
(In reply to comment #23)
> Having the same problem again but with another pdf
> <..>
> what kind of output do you guys need?
Some kind of (debug) output was needed on FreeType's bug tracker:
https://savannah.nongnu.org/bugs/?53739#comment5
In case, if it wasn't reproducible:
https://savannah.nongnu.org/bugs/?53739#comment3
But before this, there was a need for "a PDF (unencrypted) or its embedded fonts" to "further analyze" this:
https://savannah.nongnu.org/bugs/?53739#comment2

On the other hand, this PR showed, that previous issue was fixed with using Ghostscript 9.23 update. The same was for bug #213129 (e.g. bug #213129, comment #7).
Possible to find some pdf related commits after 9.23 release:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=a03872ea339d60055fa09dc451ebf37442f467fb
http://git.ghostscript.com/?p=ghostpdl.git&a=search&h=HEAD&st=commit&s=pdf
http://git.ghostscript.com/?p=ghostpdl.git&a=search&h=ae5fddd0bd7b06215235090470d3f9297faa24bb&st=commit&s=pdf

There is a Ghostscript bug tracker, for example:
https://bugs.ghostscript.com
https://bugs.ghostscript.com/describecomponents.cgi?product=Ghostscript

Since somebody already used pdffonts program from graphics/poppler-utils port:
https://savannah.nongnu.org/bugs/?53739#comment1
-8<--
% pkg which -o `which pdffonts`
/usr/local/bin/pdffonts was installed by package graphics/poppler-utils
-->8-

I may recommend to check jpeg output for new test.pdf file with using "pdftoppm" program:
% pdftoppm -jpeg test.pdf image

If it's ok, this may show that there is a possibility, that this is a Ghostscript related issue (and/or how it uses newer FreeType library). But possible to find FreeType related commit, if using "git bisect" (as described on #comment 5, for example).
Otherwise, also try to check previous Ghostscript version(s), for example, as described on comment #13 (e.g. DEFAULT_VERSIONS+=ghostscript=9 in /etc/make.conf and rebuild/reinstall Ghostscript related ports).
Comment 25 Pascal Christen 2018-08-10 09:22:27 UTC
(In reply to lightside from comment #24)
> I may recommend to check jpeg output for new test.pdf file with using
> "pdftoppm" program:
> % pdftoppm -jpeg test.pdf image

Ok, tested that and it seems like a ghostscript problem. What I've tested so far:

Test 1:
freetype2-2.9.1                Free and portable TrueType font rendering engine
ghostscript9-agpl-base-9.23    PostScript and PDF interpreter

pdftoppm -jpeg test.pdf pdftoppm.jpg -> Works fine
convert -density 300 -colorspace sRGB -resize 50% -border 2 test.pdf[0] convert.jpg -> Font looks blurry


Test 2:
freetype2-2.9.1                Free and portable TrueType font rendering engine
ghostscript9-agpl-base-9.16_5    PostScript and PDF interpreter

pdftoppm -jpeg test.pdf pdftoppm.jpg -> Works fine
convert -density 300 -colorspace sRGB -resize 50% -border 2 test.pdf[0] convert.jpg -> Font looks blurry

Test 3:
freetype2-2.8.1                Free and portable TrueType font rendering engine
ghostscript9-agpl-base-9.16_5    PostScript and PDF interpreter

pdftoppm -jpeg test.pdf pdftoppm.jpg -> Works fine
convert -density 300 -colorspace sRGB -resize 50% -border 2 test.pdf[0] convert.jpg -> Works fine

Test 4:
freetype2-2.8.1                Free and portable TrueType font rendering engine
ghostscript9-agpl-base-9.23    PostScript and PDF interpreter

pdftoppm -jpeg test.pdf pdftoppm.jpg -> Works fine
convert -density 300 -colorspace sRGB -resize 50% -border 2 test.pdf[0] convert.jpg -> Works fine

So what do you think?
Comment 26 Pascal Christen 2018-08-10 09:23:34 UTC
(In reply to Pascal Christen from comment #25)
> Ok, tested that and it seems like a ghostscript problem. What I've tested so far:
I mean freetype, sorry
Comment 27 lightside 2018-08-10 12:55:52 UTC
(In reply to comment #25)
> convert -density 300 -colorspace sRGB -resize 50% -border 2 test.pdf[0]
> convert.jpg -> Font looks blurry
> <..>
> So what do you think?
If "Font looks blurry", then this may be different issue. Previous issue was related to not readable characters for output image(s).

The print/freetype2 v2.9 changed defaults from LCD_FILTERING ("Subpixel rendering (patented)") to LCD_RENDERING ("Harmony LCD rendering") option. See bug #225072 for details. So, possible to check new output after LCD_FILTERING option usage for print/freetype2 port, if this is the case. Personally, I reported about some differences for emulators/wine-devel port in bug #228518, comment #4, but it was also related to used fontconfig configuration.

Otherwise, since I don't have required pdf to test (to find related Git commit, with using `git bisect`), I may just guess, that if pdftoppm output was ok and it used the same FreeType library:
-8<--
% sh -c "pdftoppm --help 2>&1" | grep freetype
  -freetype <string>       : enable FreeType font rasterizer: yes, no
% pdftoppm -freetype yes -jpeg test.pdf image
% pdftoppm -freetype no -jpeg test.pdf image
-->8-

then this issue might be Ghostscript related (and/or how it uses FreeType library).

The pdftoppm program doesn't use Ghostscript, as far as I know. You could check this, if you delete installed ghostscript ports (e.g. create backup packages: `pkg create -x ghostscript`, delete: `pkg delete -fx ghostscript`, reinstall after check: `pkg add ghostscript*`) and run the same pdftoppm commands.

You can check ImageMagick's convert program about Ghostscript usage, if you run it with using -verbose option:
-8<--
% convert --help | grep verbose
  -verbose             print detailed information about the image
% convert -verbose test.pdf output.jpg
'gs' -sstdout=%stderr <..>
% pkg which -o `which gs`
/usr/local/bin/gs was installed by package print/ghostscript9-agpl-base
-->8-

If you want, you can report about (new) issue to Ghostscript and/or FreeType bug trackers. Probably, they may ask about needed information (e.g. tested pdf (and/or used fonts), expected output image(s), etc.) and to check development version(s) for possible fixes. If fix is available, then possible to propose it for related FreeBSD port(s) before new available release version (but this may depend from amount of required changes, of course).
Comment 28 Pascal Christen 2018-08-10 14:10:48 UTC
(In reply to lightside from comment #27)
> If "Font looks blurry", then this may be different issue. Previous issue was
> related to not readable characters for output image(s).
Yes, actually it's not blurry. It's unreadable like the same issue before.


pdftoppm -freetype no -jpeg test.pdf image2
Syntax Error: Couldn't create a font for 'AgfaRotisSansSerif-Italic'
Syntax Error: Couldn't create a font for 'AgfaRotisSansSerif Italic'

it doesn't work without freetype. And yes you're right, pdftoppm doesn't use ghostscript. So I still don't know if it's a freetype or ghostscript related issue so I will open a bug request on both.

Thanks for your help!
Comment 29 Pascal Christen 2018-08-14 08:40:30 UTC
https://savannah.nongnu.org/bugs/?53739

Sent me back to this issue. What kind of debug output will get us a step closer?
Comment 30 lightside 2018-08-14 21:36:59 UTC
(In reply to comment #29)
> https://savannah.nongnu.org/bugs/?53739
> Sent me back to this issue.
You didn't provide a (public) testcase, i.e. all required information to reproduce (new) issue on developer's machine. For example: the test.pdf file to test, command(s) to run, broken and expected output image(s), etc.

Probably, you can't share needed information, because of embedded commercial/copyrighted font(s), confidential text in pdf, etc. Perhaps, there is solution for this, if find/create pdf file, which uses public font(s) and text, which reproduces (new) issue. Then possible to share this pdf file with developers, so they can (try to) confirm this issue and test solution(s) for it.

If text was readable, but blurry somehow, then possible to try to use png output (instead of jpg):
% convert -verbose test.pdf image.png
or "-alpha remove" option for jpg output, if this was the case:
% convert -verbose -alpha remove test.pdf image.jpg

You can try to check some stackoverflow.com pages about mentioned issue and solutions:
https://stackoverflow.com/questions/6605006/convert-pdf-to-image-with-high-resolution
https://stackoverflow.com/questions/15769623/imagemagick-convert-pdf-to-jpeg-has-poor-text-quality-after-upgrading-imagemagic

(In reply to comment #29)
> What kind of debug output will get us a step closer?
If you need some kind of debug output, I tried to explain how to create it on comment #6 and comment #7.

On the other hand, you can try to wait response from actual maintainer(s). But need to note, that Ghostscript (doceng@ for print/ghostscript9-agpl-base) and ImageMagick (kwm@ for graphics/ImageMagick) ports have different assigned maintainers, than FreeType (gnome@ for print/freetype2).

Or just use other method(s)/tool(s), which works. Also possible, that this (new) issue maybe fixed in next version(s) of affected software.
Comment 31 Pascal Christen 2018-08-16 11:05:45 UTC
Created attachment 196251 [details]
How the font looks like
Comment 32 Pascal Christen 2018-08-16 11:11:55 UTC
(In reply to lightside from comment #30)

Thanks for your help. i really appreciate it

> If text was readable, but blurry somehow, then possible to try to use png
> output (instead of jpg):
No actually it's not blurry. Check my new attachment I've just uploaded.

> Probably, you can't share needed information, because of embedded
> commercial/copyrighted font(s), confidential text in pdf
Yes that's right at the moment. But trying to get a cleared one...

> If you need some kind of debug output, I tried to explain how to create it on
> comment #6 and comment #7.
Ok, does it help if I upload the debug output of freetype2?
Comment 33 lightside 2018-08-17 02:56:56 UTC
(In reply to comment #32)
> Yes that's right at the moment. But trying to get a cleared one...
Possible to use following Python script to create test.pdf file, based on TrueType font.ttf in the same directory and installed print/py-reportlab port (tested for v3.2.0):
-8<--
import reportlab.rl_config
#reportlab.rl_config.warnOnMissingFontGlyphs = 0
from reportlab.pdfbase import pdfmetrics
from reportlab.pdfbase.ttfonts import TTFont
pdfmetrics.registerFont(TTFont("EmbeddedFont", "font.ttf"))
from reportlab.pdfgen import canvas

text="The quick brown fox jumps over the lazy dog"
c = canvas.Canvas("test.pdf")
size=32
c.setFont("EmbeddedFont", size)
c.drawString(20, 800, "EmbeddedFont, %s:" % size)
c.drawString(20, 760, text)

size=26
c.setFont("Helvetica", size)
c.drawString(20, 720, "Helvetica, %s:" % size)
c.drawString(20, 680, text)
c.showPage()
c.save()
-->8-

% python2.7 create_pdf.py
% convert -verbose -alpha remove test.pdf image.jpg

But other font types may need other methods to use.

(In reply to comment #32)
> Ok, does it help if I upload the debug output of freetype2?
I guess, that the simple answer is no, unless this was asked by concrete developer, who may understand such debug output and try to fix something, without actual pdf file or font(s) to test.
But you can try to provide such debug output for VER-2-8-1 (where there was no issue):
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tag/?h=VER-2-8-1
VER-2-9-1 (where issue was found):
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tag/?h=VER-2-9-1
and latest master commit on (in case of extended debug output for latest development version and possible fix to test):
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/
if such developer asked about this. Probably, other developers also may find some useful information in it, if freetype2 debug output is available for new issue. But I can't say about private information for such output. So, you may need to determine this by yourself (or ask others about this).

Another answer was "I need a PDF (unencrypted) or its embedded fonts that I can further analyze.", which was said by Werner Lemberg: 
https://savannah.nongnu.org/bugs/?53739#comment2
after some pdffonts output on:
https://savannah.nongnu.org/bugs/?53739#comment1
and, I guess, developer didn't have such embedded font(s) available to test on this stage.

Personally, I provided some freetype2 debug output for previous issue, after it was confirmed for print/ghostscript9-agpl-base v9.16 and print/freetype2 v2.9.1 on FreeBSD. Later it was confirmed, that previous issue was fixed after update of print/ghostscript9-agpl-base to 9.23 version in ports r472239. The Ghostscript v9.23 was used by Werner Lemberg to test for provided anonyme_visitenkarte.pdf file, which is possible reason why previous issue wasn't confirmed (the print/ghostscript9-agpl-base was v9.16 at this time):
https://savannah.nongnu.org/bugs/?53739#comment3

Need to mention again, that (automated) git bisect found 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit (see comment #3):
https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=75cb071b3fbfa2315c5d458fee2bb465a14568ae
There is some patch to test (attachment #193012 [details]) for previous issue. Possible to test this for new issue, if repeat commands in previous comment(s), but for new test.pdf, instead of previous anonyme_visitenkarte.pdf (may need to change values for TEST_SOURCE and expected_checksum variables in test.sh script from attachment #194200 [details]). The git bisect may find another commit, of course.

The current latest Ghostscript release version is 9.23 (https://ghostscript.com). If developers still use such release version, then there is a possibility, that they can confirm new issue and try to investigate, propose some fix(es), in which case need to test development version(s) of affected software, but currently only reporter(s) may confirm (and try to fix) this, if I understood this correctly.

Sorry for the long comment.
Comment 34 lightside 2018-08-17 03:15:54 UTC
(In reply to comment #34)
> Need to mention again, that (automated) git bisect found
> 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit (see comment #3)
But this doesn't (automatically) mean, that this is print/freetype2 only issue. For example, the previous issue was fixed by print/ghostscript9-agpl-base update. There is convert (from graphics/ImageMagick) usage also, which may use different -sDEVICE values for gs command, based on /usr/local/etc/ImageMagick-6/delegates.xml.
Comment 35 Pascal Christen 2018-08-17 08:56:09 UTC
Created attachment 196273 [details]
pdf test file

Ok, I just created an unencrypted and cleaned pdf with using the font "AgfaRotisSansSerif"
Comment 36 lightside 2018-08-18 01:30:24 UTC
Created attachment 196303 [details]
The freetype2 debug output for test_empty.pdf (Ghostscript 9.23)

(In reply to comment #35)
> Ok, I just created an unencrypted and cleaned pdf with using the font
> "AgfaRotisSansSerif"
The (automated) git bisect have found the same 75cb071b3fbfa2315c5d458fee2bb465a14568ae commit for test_empty.pdf file in attachment #196273 [details] (see comment #3 for git bisect log).

Used following changes for test.sh in attachment #194200 [details]:
-8<--
<..>
TEST_SOURCE=${WRKSRC}/../test_empty.pdf
<..>
expected_checksum="99ceb7731c525cdd6163c662e80dccff0ed0f80192dc428a529ef49c75a932d2"
<..>
do_build_test() {
	env LD_PRELOAD=./objs/.libs/libfreetype.so convert -alpha remove ${TEST_SOURCE} ${TEST_OUTPUT}
	check_errors "$1"
}
<..>
-->8-

Some (intermediate) solution was to comment FT_CONFIG_OPTION_POSTSCRIPT_NAMES define for include/freetype/config/ftoption.h (see comment #9):
% sed -i '.gpn.bak' -e 's|^\(#define FT_CONFIG_OPTION_POSTSCRIPT_NAMES.*\)|/* \1 */|' include/freetype/config/ftoption.h

Attached freetype2 debug output (with using FT2_DEBUG="any:5" environment variable) for VER-2.8:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tag/?h=VER-2-8
VER-2.9.1:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tag/?h=VER-2-9-1
and current master commit VER-2-9-1-183-gc94162a22:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=c94162a2200c16e9614289cf91d6bf0e0b01a01f

Some difference between VER-2-8 (where it worked) and VER-2-9 (VER-2-9-1-183-gc94162a22) for 5.txt output was:
-8<--
tt_face_lookup_table: 0x807869da8, `CBLC' -- could not find table
tt_face_lookup_table: 0x807869da8, `CBDT' -- could not find table
-->8-
---

Commands to create freetype2 debug output (after git checkout for needed commit) was:
-8<--
% setenv OUTPUT `git describe`
% echo $OUTPUT
% mkdir -p ../output/$OUTPUT
% ../test.sh build
<..>
% git show -s --format="# %s%n# https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=%H" > ../output/$OUTPUT/commit.txt
% env FT2_DEBUG="any:5" LD_PRELOAD=./objs/.libs/libfreetype.so sh -c "convert -alpha remove ../test_empty.pdf image.jpg 2>&1 | tee ../output/$OUTPUT/5.txt"
<..>
% cp -p image.jpg ../output/$OUTPUT/
% ../test.sh clean
-->8--

To Pascal Christen:
I guess, you can try to share test_empty.pdf file in attachment #196273 [details] with related developers.
If you want, you can try to continue discussion on:
https://savannah.nongnu.org/bugs/?53739

As far as I know, the accepted solution for changes in 75cb071b3fbfa2315c5d458fee2bb465a14568ae wasn't found in this PR.
Only suggestions to directly use gs or pdftoppm program, instead of convert, or comment FT_CONFIG_OPTION_POSTSCRIPT_NAMES define for include/freetype/config/ftoption.h before freetype2 build, e.g. for custom libfreetype.so library and env LD_PRELOAD=path/to/libfreetype.so usage for convert program (see comment #9).
Comment 37 lightside 2018-08-20 02:06:14 UTC
Created attachment 196368 [details]
The print/ghostscript9-agpl-base for test (4ade82d)

I tested ImageMagick's convert program for development 9.24 version of Ghostscript, based on current master commit:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=4ade82d9471971937ff3bcb39823cb080a18c2d5

Looks like, it contains fixes for test_empty.pdf file in attachment #196273 [details]. This may mean, that next Ghostscript release version may contain fixes for (new) issue.

I attached archive with modified print/ghostscript9-agpl-base port, which I used to test.

Possible to find exact commit(s), which fixed (new) issue, for example, with using manual git bisect and different GIT_COMMIT values for modified print/ghostscript9-agpl-base port. But this may require further investigation.
Comment 38 lightside 2018-08-20 03:14:08 UTC
Comment on attachment 196368 [details]
The print/ghostscript9-agpl-base for test (4ade82d)

I obsoleted attachment #196368 [details], because the long description increased the width of messages in this PR.
But possible to download it, if needed.
Comment 39 lightside 2018-08-20 03:37:20 UTC
Comment on attachment 196368 [details]
The print/ghostscript9-agpl-base for test (4ade82d)

Returned attachment #196368 [details] with short description.
But looks like, this doesn't change the width of messages much for logged users, because of single-line service messages. Sorry for inconvenience.
Comment 40 lightside 2018-08-20 20:09:17 UTC
Created attachment 196397 [details]
Proposed patch for print/ghostscript9-agpl-base (since 473400 revision)

The (manual) git bisect have found following commit, which fixes new issue:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8ec5c5ded5fc19cabd95dad385b22a506e59acaf
-8<--
zfapi.c: another case of is_glyph_index set wrongly

This is related to freetype now a) automatically selecting a Unicode cmap for
every font, if one is available, and b) automatically generating a Unicode cmap
for every font when one is not available.

Logic that we had pushed down to the FAPI/FT interface layer, we now need to
apply earlier.
-->8-

The git bisect log:
-8<--
git bisect start
# new: [4ade82d9471971937ff3bcb39823cb080a18c2d5] Fix a minor compiler warning
git bisect new 4ade82d9471971937ff3bcb39823cb080a18c2d5
# old: [cfada4acb65861b4361ad80dbb53f61c5dc94c96] Bump version - prep for release
git bisect old cfada4acb65861b4361ad80dbb53f61c5dc94c96
# new: [dc20112ef13ebdfc6e1ad20ac9ef5462e9145682] Fix a compiler warning
git bisect new dc20112ef13ebdfc6e1ad20ac9ef5462e9145682
# new: [c0f89bd215d700339429da4375a4eaf89445f872] jbig2dec: Remove unnecessary whitespace.
git bisect new c0f89bd215d700339429da4375a4eaf89445f872
# old: [d411d72de4d41e0ad436c50d89088dc13e3b3f42] Shared library compiler warnings: lcms2, openjpeg
git bisect old d411d72de4d41e0ad436c50d89088dc13e3b3f42
# new: [bc817a3afdb932eadac17155834f89efd1c96da4] Bring libpng up to 1.6.34
git bisect new bc817a3afdb932eadac17155834f89efd1c96da4
# new: [8ec5c5ded5fc19cabd95dad385b22a506e59acaf] zfapi.c: another case of is_glyph_index set wrongly
git bisect new 8ec5c5ded5fc19cabd95dad385b22a506e59acaf
# old: [781c6a90b501a7cfcf1cdd337344444e6b388ef6] Address some compiler warnings adding casts
git bisect old 781c6a90b501a7cfcf1cdd337344444e6b388ef6
# old: [e3ef00ae7bd46ac4c45bf67cbb03a2342e850dca] Fix PACIFY_VALGRIND build
git bisect old e3ef00ae7bd46ac4c45bf67cbb03a2342e850dca
# old: [6e4ac5e7f1e8ea1835a99f12a7a4e34ebd85261e] Bug 699141: add configure test for __restrict in compiler
git bisect old 6e4ac5e7f1e8ea1835a99f12a7a4e34ebd85261e
# first new commit: [8ec5c5ded5fc19cabd95dad385b22a506e59acaf] zfapi.c: another case of is_glyph_index set wrongly
-->8-

Attached patch for print/ghostscript9-agpl-base port. Please test.
Also fixed following portlint's error:
FATAL: Makefile: [25]: use a tab (not space) after a variable name

To Pascal Christen:
Thanks for your assistance and test_empty.pdf file in attachment #196273 [details] for test(s), which helped to find upstream fix for new issue in Ghostscript 9.23 release.
Comment 41 lightside 2018-08-20 23:17:28 UTC
(In reply to comment #37)
> Possible to find exact commit(s), which fixed (new) issue, for example, with
> using manual git bisect and different GIT_COMMIT values for modified
> print/ghostscript9-agpl-base port.
In this case, I used local ghostpdl repository for manual git bisect and copy of its directories/files instead of extracted distfile of print/ghostscript9-agpl-base port (i.e. after `make extract`, but empty ${WRKSRC} directory), then `make check-plist`, `make deinstall`, `make install` commands and manual testing for next stage of git bisect (i.e. `convert -alpha remove test_empty.pdf image.jpg && sha256 image.jpg`). Then marked related commit(s) as `git old` or `git new` (if there was a fix).

Also was needed to develop some "universal" sed patches for print/ghostscript9-agpl-base port, which was applicable between many commits. Some of them available in attachment #196368 [details]. Others was:
-8<--
	@${REINPLACE_CMD} -e '/^install-data:/s|install-doc||' \
		${WRKSRC}/base/unixinst.mak
	@${REINPLACE_CMD} -e '/ 199901L/s|==|>=| ; \
		/ 199901L/s|$$|\${.newline}#define gs_restrict restrict|' \
		${WRKSRC}/base/stdpre.h
-->8-
and commented "${RLN} ${STAGEDIR}${DOCSDIR} ${STAGEDIR}${DATADIR}/doc" command on post-install stage, because there were some issues with documentation installation for some commits (but `git bisect skip` wasn't a variant to use).

Probably, there are other ways about how to test Ghostscript, including without its install. But I used available build and package systems on FreeBSD, for this case.
Comment 42 lightside 2018-08-20 23:28:03 UTC
(In reply to comment #41)
> Then marked related commit(s) as `git old` or `git new` (if there was a fix).
The `git bisect old` (if wasn't fixed) or `git bisect new` (if there was a fix).
Comment 43 Pascal Christen 2018-08-21 07:25:07 UTC
(In reply to lightside from comment #40)

> To Pascal Christen:
> Thanks for your assistance and test_empty.pdf file in attachment #196273 [details]
> [details] for test(s), which helped to find upstream fix for new issue in 
> Ghostscript 9.23 release.

Thanks for your effort you put into that issue. I've just tried your patch and it works!
Comment 44 Pascal Christen 2018-09-03 13:55:48 UTC
Still no feedback from doceng@FreeBSD.org
Comment 45 lightside 2018-09-04 17:48:58 UTC
(In reply to comment #44)
Looks like, print/ghostscript9-agpl-base (and print/ghostscript9-agpl-x11) was updated to 9.24 version in ports r478951.

The Ghostscript v9.24 contains fixes, which was proposed in attachment #196397 [details]:
https://ghostscript.com/Ghostscript_9.24.html
https://ghostscript.com/doc/9.24/History9.htm
https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8ec5c5ded5fc19cabd95dad385b22a506e59acaf
Comment 46 Pascal Christen 2018-12-27 14:35:04 UTC
Guess it's resolved