Slack 11.0 patch source code freetype-2.3.4
 

Hi,

From the latest patches, from the source folder, I downloaded the folder named freetype.

Running the freetype.SlackBuild works fine. It compiles, builds a package.

But it will not make a package if I enable the byte code interpreter line inside freetype.SlackBuild

It reports "hunk" and some other errors, there is no compiling and no package is made.

freetype 2.1.9 did not have this problem. (2.1.9 worked ok with the bytecode interpreter line enabled)

Can someone explain to me what to do so I can make/get my own freetype-2.3.4 Slack 11.0 package with the byte code interpreter enabled?

--
Alan.

Hi

I made a diff below. Hope this work.

--- CUT ---
diff -Nru freetype-2.3.4.orig/include/freetype/config/ftoption.h freetype-2.3.4.new/include/freetype/config/ftoption.h
--- freetype-2.3.4.orig/include/freetype/config/ftoption.h 2007-04-21 17:49:37.000000000 +0900
+++ freetype-2.3.4.new/include/freetype/config/ftoption.h 2007-04-21 17:52:16.000000000 +0900
@@ -456,7 +456,7 @@
/* Do not #undef this macro here, since the build system might */
/* define it for certain configurations only. */
/* */
-/* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */
+#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER


/*************************************************************************/
--- CUT ---

Here is another variant. Get it here: Or from here:

Ah, I had not read the comments too closely that you find right above ... so if you leave that enabled while also enabling , it looks as if the patented algorithms still are not compiled in?
I.e. Petri Kaukasoina's patch with #define TT_CONFIG_OPTION_UNPATENTED_HINTING commented out is the one that should work?

Eric

I think so because of this mail:

http://lists.gnu.org/archive/html/fr.../msg00064.html

(David Turner is a freetype developer).

Hi. Due to business elsewhere, I just now checked in and, at this time, there's 4 replies plus my original, which equals 5 posts. And this post right here now makes a total of 6 posts so far.

(per above quote) I just wget'ed the diff.gz file.
--

al@p3srv:/mnt/sata/install/freetype234$ ls
freetype-2.3.4.tar.bz2
freetype-2.3.4.tar.bz2.sig
freetype.SlackBuild*
freetype.build*
freetype.bytecode.interpreter.diff.gz
freetype.bytecode.interpreter_slack_orig.diff.gz
freetype.illadvisederror.diff.gz
freetype_ac.SlackBuild*
slack-desc

There, you can see the (and also my customized contents) contents of the patches/source/freetype folder (I later renamed the folder to freetype234).

Before I wget'ed the mentioned diff.gz file, I (as it's seen above) renamed the original to "freetype.bytecode.interpreter_slack_orig.diff.gz"

Then I merely wget'ed the replacement into this folder.

I then (as it's seen above) made a copy of freetype.SlackBuild named freetype_ac.SlackBuild

I then edited and saved the change on that latter file, did enabled the bytecode interpreter line.

Next, I ran ./freetype_ac.SlackBuild

And it compiled, built a package.

I then renamed that package from: freetype-2.3.4-i486-1_slack11.0.tgz to freetype-2.3.4-i486-1_ac.tgz

# removepkg freetype-2.1.9-i486-1_ac.tgz

# installpkg freetype-2.3.4-i486-1_ac.tgz

I then logged out of KDE which reverts me back to run level 3 and into the first or logon terminal.

al@p3srv:~$ startx

The fonts are now better yet than they ever were before (they were pretty darn good with freetype 2.1.9).
--

Linux fonts have been so good for a while now that it may now be a mute point to 1. add in msttf (ms true type fonts) and to 2. do this bytecode interpreter enabling thing.

But I'm not touching my fonts (since they're working so good at this time) as in "if it ain't broke, don't fix it."
--

As a guess, I'd guess that instead of my wget'ing that diff.gz file, I, instead, could have copied the contents as shared (next to the wget url) and then pasted that into an editor and then save it as a file named: freetype.bytecode.interpreter.diff

And then gzip that file so as to end up with: freetype.bytecode.interpreter.diff.gz

Another guess: I guess that's called a patch? Can someone confirm?

Lastly, can anyone share a good www site on the (very) basics or getting started learning of patch?

I guess (in a nutshell) a patch applies a diff to a former (or a pre existing) file during the compiling. Thus, this is a way of "on the fly" (or dynamically so to speak) obtaining an updated or altered outcome during the compiling. (am I correct here, on what I said in this paragraph?).

Thanks.

--
Alan.

The fixed patch for the bytecode interpreter and the new patch for enablement of the subpixel rendering are now incorporated into the latest freetype package update in Slackware-current.
Go get it.

Eric

I got the (Slack-Current) fixed patch source from a mirror.

Works very fine. Fonts appear at least as good; but, really (if there *really* is such a thing in existence as really)

Which reminds me of the book author Scott Peck's take on this where he states: "we can only approach reality".

So, (really) the fonts appear yet even a tiny bit better now.
--

FWIW

http://beranger.org/index.php?article=2787

Helped me to see what's been/is going on regards this arena.

I've a CRT monitor here.

I don't know how to (only for an LCD monitor) enable sub pixel hinting A.K.A. ClearType in KDE. But that's a whole another (KDE) topic.

--
Alan.

does not work for me:mad:
applied the patch in the slackbuild, but fonts still not ok
back to 2.1.9, works perfect, but i know it's a security risk

Well, now I tried both TT_CONFIG_OPTION_UNPATENTED_HINTING defined and not. I could not see any difference between the two. So, I guess this comment in the options file means that it takes some effort at runtime to get the unpatented version on the screen: