> Unless I've misunderstood, It seems to me that the changes being
> made are not to amalgamate FreeType into a couple of files, but just
> to rename some stuff/change some #defines to make this possible for
> another tool to optionally do.
Exactly. No need to further discuss that. I've accepte
> How about a shared header file if those modules share a structure?
> Don't you see that this patch set is just a pile of pure stinking
> crap???
Alexei, your comments are at the border of insults. Please don't do
that! We already know that you don't like the patches. It doesn't
help at all i
Well here it is, an amalgamated version of FreeType. It compiles, links, and
functions correctly in my host application (which was previously linking with a
version of FreeType built as a static library from the full source tree on my
machine). This is only a first draft, plenty of rough edges h
One more minor set of changes, I moved an inline comment to the previous
line on a couple of #include lines.
2012-02-21 Vinnie Falco
[7] ftvalid.h, ftobjs.c, ftraster.c: moved #include comment to previous line
Thanks
7.patch
Description: Binary data
On Tue, Feb 21, 2012 at 11:54 AM, Vinnie wrote:
>
>
>> From: Alexei Podtelezhnikov
>> Sent: Tuesday, February 21, 2012 8:28 AM
>>
>> It is hard to believe that there are people who'll dive into font rendering
>> without first learning how to use multiple files and libraries in a project.
>
> I ag
> From: Alexei Podtelezhnikov
> Sent: Tuesday, February 21, 2012 8:28 AM
>
> It is hard to believe that there are people who'll dive into font rendering
> without first learning how to use multiple files and libraries in a project.
I agree, it is hard to believe but that's just how it is. For s
On Tue, Feb 21, 2012 at 11:03 AM, Chris Morgan wrote:
> Hey. This kind of response isn't cool man.
>
> If Vinnie's patches disambiguate and otherwise clarify the code then
> they are good changes, even if it enables him to do things that we
> find odd.
There is nothing ambiguous in FreeType code.
On Tue, Feb 21, 2012 at 12:07 PM, Dmitry Timoshkov wrote:
> Vinnie wrote:
>
>> > How about providing a single precompiled library file for these people?
>>
>> That would only work for one particular build environment, and within that
>> environment, only one target. For example, debug, or release
On Tue, Feb 21, 2012 at 10:44 AM, Vinnie wrote:
>> Date: Tue, 21 Feb 2012 08:02:43 -0500
>
>> From: Alexei Podtelezhnikov
>>
>> You planing this for Stone Age people who do not know how to use
>> make. I rest my case.
>
> Actually, that is true.
>
> My target audience includes musicians or artist
> From: Alan Coopersmith
>
> Using anything but a shared library for FreeType just seems to be begging
> for pain everytime FreeType has to issue a security fix or other critical
> fix, and suddenly you need to redeliver every single application with the
> FreeType code embedded, instead of one c
Vinnie wrote:
> > How about providing a single precompiled library file for these people?
>
> That would only work for one particular build environment, and within that
> environment, only one target. For example, debug, or release. Or 32 bit versus
> 64 bit. If the resulting FreeType library we
On 02/21/12 05:02 AM, Alexei Podtelezhnikov wrote:
All this work is from Stone Age, when noone shared and everyone
only used a single file and a single command to build something.
Using anything but a shared library for FreeType just seems to be begging
for pain everytime FreeType has to issue
On Tue, Feb 21, 2012 at 11:01 AM, Vinnie wrote:
>> From: Dmitry Timoshkov
>
>> Sent: Tuesday, February 21, 2012 8:53 AM
>>
>>> With an amalgamated version of FreeType I can add support for hinted
>>> fonts to my open source offerings, while including the entire FreeType
>>> distribution as a s
Hey. This kind of response isn't cool man.
If Vinnie's patches disambiguate and otherwise clarify the code then
they are good changes, even if it enables him to do things that we
find odd. If there are common structures that should be used then that
is valid feedback, please clarify which ones etc
> From: Dmitry Timoshkov
> Sent: Tuesday, February 21, 2012 8:53 AM
>
>> With an amalgamated version of FreeType I can add support for hinted
>> fonts to my open source offerings, while including the entire FreeType
>> distribution as a single source file instead of a large tree.
>
> How abo
Vinnie wrote:
> With an amalgamated version of FreeType I can add support for hinted
> fonts to my open source offerings, while including the entire FreeType
> distribution as a single source file instead of a large tree.
How about providing a single precompiled library file for these people?
-
> Date: Tue, 21 Feb 2012 08:02:43 -0500
> From: Alexei Podtelezhnikov
>
> You planing this for Stone Age people who do not know how to use
> make. I rest my case.
Actually, that is true.
My target audience includes musicians or artists who are beginning
to dabble in C / C++ programming. The are
Unless I've misunderstood, It seems to me that the changes being made are not
to amalgamate FreeType into a couple of files, but just to rename some
stuff/change some #defines to make this possible for another tool to optionally
do.
If so, I really can't see what the problem is and why you're b
How about a shared header file if those modules share a structure?
Don't you see that this patch set is just a pile of pure stinking crap???
On Tue, Feb 21, 2012 at 9:56 AM, Vinnie wrote:
> Werner:
>
> 2012-02-20 Vinnie Falco
>
>
> ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename
Werner:
2012-02-20 Vinnie Falco
ftgrays.c, ftraster.c: Undefine RAS_ARG* and RAS_VAR*, rename PRaster, TRaster
Attached is the change you requested to undefined the RAS_* macros.
Thanks,
Vinnie
4.patch
Description: Binary data
___
Freetype-dev
Alexei Podtelezhnikov wrote:
> All this work is from Stone Age, when noone shared and everyone
> only used a single file and a single command to build something.
I tend to agree, I somehow doubt that there is a single project out there
that would even consider accepting this kind of patches.
--
All this work is from Stone Age, when noone shared and everyone
only used a single file and a single command to build something.
You will make people who borrow from FreeType miserable and make
them curse at you for renaming stuff for no good reason whatsoever.
Yes, taking smooth out of FreeType f
On Tue, Feb 21, 2012 at 4:11 AM, Antoine Leca
wrote:
> Alexei Podtelezhnikov wrote:
>> Why do you butcher perfectly legal code C-code?
>> You problem is in the tool - not it in FreeType.
> This is not fair. The exercise do show some areas in Freetype which code
> will be clearly made better after
Alexei Podtelezhnikov wrote:
> Why do you butcher perfectly legal code C-code?
> You problem is in the tool - not it in FreeType.
This is not fair. The exercise do show some areas in Freetype which code
will be clearly made better after the corrections proposed by Vinnie.
Examples are the #undef pp
24 matches
Mail list logo
