GitLab

reverting the behavior accidentally changed by 12b750

https://bugs.freedesktop.org/show_bug.cgi?id=102141

https://bugs.freedesktop.org/show_bug.cgi?id=78452

Applied optimizations:
- skip duplicate check in FcStrSetAppend for values originating from readdir()
- grow FcStrSet in 64-element bulks for local FcStrSets (FcConfig layout unaltered)

Starting gedit is measured to

                        Unoptimized     Optimized
user[s]                         0,806         0,579
sys[s]                          0,062         0,062
Total Instr Fetch Cost: 1.658.683.750   895.069.820
Cachegrind D Refs:        513.917.619   312.000.436
Cachegrind Dl Misses:       8.605.632     4.954.639

and remove the unnecessary code for parsing blanks

segfault happens when the config needs to be migrated to XDG's
and no definition for include with prefix="xdg"

Reported by Jia Wang

https://bugs.freedesktop.org/show_bug.cgi?id=83770

Paths starting with '/' don't make sense on W32 as-is,
prepend the installation root directory to them.

This allows the cache to be contained within a particular
fontconfig installation (as long as the default
--with-cache-dir= is overriden at configure time).

Fix for e96d7760

https://bugs.freedesktop.org/show_bug.cgi?id=59456

This feature requires the FreeType 2.5.1 or later at the build time.

Besides <range> element allows <double> elements with this changes.

This may breaks the cache but not bumping in this change sets at this moment.
please be aware if you want to try it and run fc-cache before/after to
avoid the weird thing against it.

Use FcTypeUnknown instead of -1 with type casting.
This seems missed when it was changed.

Patch from brian porter

This corrects an error message being reported at
  https://bugs.freedesktop.org/show_bug.cgi?id=71085
  Bug 71085 - "out of memory" errors on empty match element in fonts.conf

and somewhat works as a workaround for
  https://bugs.freedesktop.org/show_bug.cgi?id=59438
  Bug 59438 - Fix <alias> inside <match>

to get the following recipe working:

<match>
  <test1 .../>
  <edit1 .../>
  <test2 .../>
  <edit2 .../>
</match>

as:

<match>
  <test1 .../>
  </edit1 .../>
</match>
<match>
  <test1 .../>
  <test2 .../>
  <edit2 .../>
</match>

This change reverts 9acc14c3
because it doesn't work as expected when building
with -fshort-enums which is default for older arms ABIs

Thanks for pointing this out, Thomas Klausner, Valery Ushakov, and Martin Husemann

Add two edit mode, "delete" and "delete_all".
what values are being deleted depends on <test> as documented.
if the target object is same to what is tested, matching value there
will be deleted. otherwise all of values in the object will be deleted.
so this would means both edit mode will not take any expressions.

e.g.

Given that the testing is always true here, the following rules:

  <match>
    <test name="foo" compare="eq">
      <string>bar</string>
    </test>
    <edit name="foo" mode="delete"/>
  </match>

will removes "bar" string from "foo" object. and:

  <match>
    <test name="foo" compare="eq">
      <string>foo</string>
    </test>
    <edit name="bar" mode="delete"/>
  </match>

will removes all of values in "bar" object.

This changes allows to have multiple mathcing rules in one <match> block
in the same order.
After this changes, the following thing will works as two matching rules:

	<match>
		<!-- rule 1 -->
		<test name="family" compare="eq">
			<string>foo</string>
		</test>
		<edit name="foo" mode="append">
			<string>foo</string>
		</edit>
		<!-- rule 2 -->
		<test name="foo" compare="eq">
			<string>foo</string>
		</test>
		<edit name="foo" mode="append">
			<string>bar</string>
		</edit>
	</match>

The type will be resolved at runtime...

For example, we can do this now without getting a warning:

<match target="font">
  <test name="scalable" compare="eq">
    <bool>false</bool>
  </test>
  <edit name="pixelsizefixupfactor" mode="assign">
    <divide>
      <name target="pattern">pixelsize</name>
      <name target="font"   >pixelsize</name>
    </divide>
  </edit>
  <edit name="matrix" mode="assign">
    <times>
      <name>matrix</name>
      <matrix>
        <name>pixelsizefixupfactor</name> <double>0</double>
        <double>0</double> <name>pixelsizefixupfactor</name>
       </matrix>
    </times>
  </edit>
  <edit name="size" mode="assign">
    <divide>
      <name>size</name>
      <name>pixelsizefixupfactor</name>
    </divide>
  </edit>
</match>

Previously the last edit was generating:

Fontconfig warning: "/home/behdad/.local/etc/fonts/conf.d/00-scale-bitmap-fonts.conf", line 29: saw unknown, expected number

Based on idea from Raimund Steger.

For example, one can do something like this:

<match target="font">
  <test name="scalable" compare="eq">
    <bool>false</bool>
  </test>
  <edit name="pixelsizefixupfactor" mode="assign">
    <divide>
      <name target="pattern">pixelsize</name>
      <name target="font"   >pixelsize</name>
    </divide>
  </edit>
  <edit name="matrix" mode="assign">
    <times>
      <name>matrix</name>
      <matrix>
        <name>pixelsizefixupfactor</name> <double>0</double>
        <double>0</double> <name>pixelsizefixupfactor</name>
       </matrix>
    </times>
  </edit>
</match>

Part of work to make bitmap font scaling possible.  See thread
discussion:

http://lists.freedesktop.org/archives/fontconfig/2012-December/004498.html

That belongs in tools like cairo/util/malloc-stat.so