<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.graphics.png.general">
    <title>gmane.comp.graphics.png.general</title>
    <link>http://blog.gmane.org/gmane.comp.graphics.png.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2484"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2482"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2481"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2472"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2468"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2466"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2465"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2456"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2419"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2415"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2412"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2407"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2406"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2395"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2391"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2389"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2381"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2379"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2378"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2372"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2484">
    <title>How to build the png source for Windows</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2484</link>
    <description>&lt;pre&gt;Hello,
I am trying to to build the latest source code (ver 1.5.6) of libpng from
here &amp;lt;http://www.libpng.org/pub/png/libpng.html&amp;gt;,(*.zip file)  I am trying
to build a libpng windows library(static or dll) on my Windows-7.

I copy the file scripts/makefile.msc to ../Makefile

then do make (CMD prompt).

I get errors. Below is the message printed on console on doing make:

cl -c -Oait -Gs -nologo -W3 -AL -Izlib .c &amp;gt;&amp;gt; pngerrs

And pngerrs(errorfile) contains error message as:

    .c
    c1 : fatal error C1083: Cannot open source file: '.c': No such file or
directory
    .c
    c1 : fatal error C1083: Cannot open source file: '.c': No such file or
directory




This is the Makefile:

    # makefile for libpng
    # Copyright (C) 1995 Guy Eric Schalnat, Group 42, Inc.
    # Copyright (C) 2006, 2009 Glenn Randers-Pehrson
    #
    # This code is released under the libpng license.
    # For conditions of distribution and use, see the disclaimer
    # and license in png.h
    #
    # Assumes that zlib.lib, zconf.h,&lt;/pre&gt;</description>
    <dc:creator>ASUDE ASUDE</dc:creator>
    <dc:date>2011-12-14T14:05:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2482">
    <title>Hang When Running the reading code.</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2482</link>
    <description>&lt;pre&gt;Folks of png-mng-misc,

I am experiencing a hang in my code at the png_create_struct when I run the
png read code.  I am using the form with three NULLs in the last three
parameters.  Any suggestions as to why?  I am running png 1.5.6.  I am
compiling successfully with g++ 3.4.4 in cygwin on top of Windows XP.
Also, when the code is present, but not called the application cannot be
killed?

Regards-

-Steve Farris
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d_______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
&lt;/pre&gt;</description>
    <dc:creator>Steven Farris</dc:creator>
    <dc:date>2011-11-26T15:11:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2481">
    <title>sRGB in PNG, v2 vs v4</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2481</link>
    <description>&lt;pre&gt;I'm working on some applications that read various image formats
that might have embedded iCC sRGB color profiles, and convert
to and from png.

In theory, it's supposed to be OK to recognize the sRGB
profile and just write the sRGB profile in the PNG.

Now comes the rub: when we read a PNG with an sRGB
chunk and write to a format that doesn't have the equivalent
of the sRGB  chunk but does allow embedded color
profiles, which sRGB profile should the application write?
There are two version-2 profiles (with and without blackpoint
compensation) and one version-4 profile which is much
larger and claimed by ICC to produce better-looking results.

I am leaning toward providing an option for the user to
select version 2 or version 4.  What should be the default?
v4 has been out for 10 years, and ICC seems to recommend
using v4 (see http://www.color.org/v4spec.xalter).

What to do about the black-point compensated one?

Currently I am recognizing these profiles by their length
and by the presence of "sRGB" at a ce&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2011-09-29T23:54:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2472">
    <title>ISO PNG - 2003 or 2004?</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2472</link>
    <description>&lt;pre&gt;Hello,

This was just brought to my attention. Seems like a clear errata item;
the ISO page is clear that the correct date is 2004.

While this might seem like an 'obvious' correction that people could
do in their head,it can cause confusion as some people might think
these are two different versions of the spec.






&lt;/pre&gt;</description>
    <dc:creator>Chris Lilley</dc:creator>
    <dc:date>2011-09-28T16:19:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2468">
    <title>If you had to do it again... 16 years later.</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2468</link>
    <description>&lt;pre&gt;Hello,
I have been playing around with PNGs for a while, looking for the best 
tools to reduce their size (the primary goal was to reduce the size of 
the themes on my Sony Ericsson K810 and Web Performance Optimization).

This led me to hack libpng to implement some kind of advanced dirty 
transparency cleaning:
http://www.libpng.org/pub/png/book/chapter09.html#INDEX-747
   "If a region is completely transparent, don't zero out the underlying 
color pixels in order to improve compression unless you've notified the 
user in some way."

Well, I did worse since cryopng actually zeroes out the output of the 
filters, that means completely transparent pixel can end up with non 
zero RGB components (the value of the reverse transformation of the 
filter indeed) those will be zeroed once filtered, thus the deflate 
engine receives more zeros, this can slightly improve compression of 
RGBA images.

Of course this is not enough to contend against pngslim like scripts, so 
I ended up writing some awful scripts that r&lt;/pre&gt;</description>
    <dc:creator>Frédéric Kayser - CryoPNG</dc:creator>
    <dc:date>2011-06-13T12:57:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2466">
    <title>Reading palette images with transforms</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2466</link>
    <description>&lt;pre&gt;How do I display a palette based (indexed) PNG with gamma correction?

I'm trying to read a PNG indexed (color type 3) image to which I've added a gamma transform (i.e. I've specified gamma values to png_set_gamma that will cause the RGB values in the palette to change.)

In my code I use the sequential reader and I call png_read_update_info.  The documentation (libpng-manual.txt - this is 1.5) says that the update call will update the palette according to the transformations (as well as updating other chunks that, as previously reported on the implementation list, don't actually get updated.)

When I look at the palette (png_get_PLTE) it is unchanged (I think).  When I look at png_read_update_info it doesn't change the palette - instead this happens later in png_init_read_transformations.  However, even if I wait until after I've read all the rows of the image I still get the old palette back because I simply can't find a way to read the transformed one (in png_struct).

I've checked back to 1.0.53 and the &lt;/pre&gt;</description>
    <dc:creator>jbowler-HInyCGIudOg&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2011-05-18T14:12:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2465">
    <title>update of PngSuite</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2465</link>
    <description>&lt;pre&gt;
Triggered by a couple of requests for updates during the last year, I've 
finally picked up (after 12 years :-) an upgrade of PngSuite.

You can find the new version at http://www.schaik.com/pngsuite2011/ but 
I expect this soon to replace the existing version at 
http://www.schaik.com/pngsuite/ .

Here are the topics that got corrected / extended, please let me know if 
you observe any errors:

= spAL chunks got replaced with sPLT chunks
= a few filenames are changed, nobody noticed the bug for more than a 
decade :-), thanks Hadrien !!!
= I added some iTXt chunks with UTF-8 text to the "ancillary chucks" 
category; I used iGoogle for the translation and although I speak four 
languages, I don't know Finnish, Greek, Hindi or Japanese, so the texts 
can be a bit crappy :-), but this is all about the correct UTF-8 
encoding; still, looking forward to improvements from our linguistic 
audience (see attached)
= the transparency images showing a NeXT logo got replaced with 
politically correct (and more boring)&lt;/pre&gt;</description>
    <dc:creator>Willem van Schaik</dc:creator>
    <dc:date>2011-04-17T05:59:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2456">
    <title>Error message: Image width is zero in IHDR</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2456</link>
    <description>&lt;pre&gt;Hello list,

Is there anything wrong with this PNG?
http://granjow.net/uploads/temp/s1.png

I get error messages:
when loading it with TV-L1[1]. No matter whether I export the PNG with GIMP 
or create it wit imagemagick.

thanks
Simon

[1] http://www.inf.ethz.ch/personal/chzach/opensource.html

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
&lt;/pre&gt;</description>
    <dc:creator>Simon A. Eugster</dc:creator>
    <dc:date>2011-03-29T08:04:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2419">
    <title>PNG is 16</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2419</link>
    <description>&lt;pre&gt;Happy birthday, etc.!

(When PNG was born, the idea of an image format having been around for 16
years, virtually unchanged, was close to inconceivable.  That's probably
still true today of things that are higher up the stack...)

Greg

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
&lt;/pre&gt;</description>
    <dc:creator>Greg Roelofs</dc:creator>
    <dc:date>2011-03-07T17:34:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2415">
    <title>PNG chunk copy-safety when IHDR changes</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2415</link>
    <description>&lt;pre&gt;I've always considered all unknown chunks to be not-copy-safe,
in ImageMagick/GraphicsMagick, regardless of the chunk-type bits,
if IHDR changes (actually I always I consider them not-copy-safe,
because the PNG encoder has no way of knowing what IM/GM has
done to the image, or if it even started out being a PNG). The PNG
spec doesn't say that changing IHDR makes all unknown chunks
not-copy-safe, but consider what happens to the validity of oFFs
and pHYs if you crop or scale the image.

I got a complaint today about ImageMagick losing the grAb chunk
which I never heard of until know, when "mogrify -trim file.png" is used.
As described to me, it's the same as oFFs without the units field,
and does actually need to have its contents modified to account
for the trim operation.

Should the next edition of the PNG spec, if there ever is one,
say something about that, or should it be obvious without any
note in the spec?

Glenn

------------------------------------------------------------------------------
Special &lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2011-01-29T15:56:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2412">
    <title>longjmp version</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2412</link>
    <description>&lt;pre&gt;
I'm half-trying to get rrdtool working under the POSIX subsystem in
Windows Server, aka Interix. I am having some trouble with programs that
use libpng failing on longjump version. Is there a way to prevent this
problem from happening


[ administrator$ ] make test
make  pngtest
gcc -DHAVE_CONFIG_H -I.    -D_ALL_SOURCE -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/ssl/include  -D_ALL_SOURCE -MT
pngtest.o -MD -MP -MF .deps/pngtest.Tpo -c -o pngtest.o pngtest.c
mv -f .deps/pngtest.Tpo .deps/pngtest.Po
/bin/sh ./libtool --tag=CC    --mode=link gcc  -D_ALL_SOURCE
-L/usr/local/ssl/lib -L/usr/local/ssl/lib -lbind -lbind -o pngtest
pngtest.o libpng12.la -lz -lm
libtool: link: gcc -D_ALL_SOURCE -o .libs/pngtest pngtest.o
-L/usr/local/ssl/lib ./.libs/libpng12.so -lbind -lz -lm
-Wl,-rpath,/usr/local/lib
/opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/../../../../i586-pc-interix3/bin/ld:
./.libs/libpng12.so: _longjmp: invalid needed version 2
./.libs/libpng12.so: could not read symbols: Bad value
collect2: &lt;/pre&gt;</description>
    <dc:creator>Eric A. Hall</dc:creator>
    <dc:date>2010-12-29T04:43:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2407">
    <title>PNG file issue</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2407</link>
    <description>&lt;pre&gt;Hi,

I am a Web Developer, and working in Linux environment. 

Recently I have created a PNG image using php5 with jpgraph tool. 
The PNG image file size is 45 KB.

After created the image I have placed/written the image into PDF file. 
For display the image in the PDF file I have used PostScript and HARU PDF functions with two different examples. 
The PDF file size is 6.5 MP.

The above examples If I used with JPEG image 
The JPG image file size is 250 KB.
The PDF file size is 500 KB.

Why the file size is too much, when using PNG file ?

Please let me know if you find any issues.

Regards,
P.karikalan.


      

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
&lt;/pre&gt;</description>
    <dc:creator>Kari kalan</dc:creator>
    <dc:date>2010-12-08T08:20:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2406">
    <title>libpng-1.4.5 is available</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2406</link>
    <description>&lt;pre&gt;libpng-1.4.5 is available from the usual sources:
ftp://ftp.simplesystems.org/pub/png/src
and from
http://libpng.sf.net

Changes since the last public release (1.4.4):

  Fixed possible configure.ac bug introduced in version 1.4.4.
  Wrapped long lines in CMakeLists.txt and introduced ${libpng_public_hdrs}
  Check for out-of-range text compression mode in png_set_text().
  Removed some extraneous parentheses that appeared in pngrutil.c of
    libpng-1.4.3
  Revised png_get_uint_32, png_get_int_32, png_get_uint_16 (Cosmin)
  Moved reading of file signature into png_read_sig (Cosmin)
  Fixed atomicity of chunk header serialization (Cosmin)
  Added test for io_state in pngtest.c (Cosmin)
  Added "#!/bin/sh" at the top of contrib/pngminim/*/gather.sh scripts.
  Changes to remove gcc warnings (John Bowler)
    Certain optional gcc warning flags resulted in warnings in libpng code.
    With these changes only -Wconversion and -Wcast-qual cannot be turned on.
    Changes are trivial rearrangements of code.  -Wconve&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2010-12-09T13:59:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2395">
    <title>weppy (WebP)</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2395</link>
    <description>&lt;pre&gt;New image format:

http://code.google.com/speed/webp/

Glenn

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2010-10-01T14:31:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2391">
    <title>PNG12_0, libpng12.so.0 on Sol10</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2391</link>
    <description>&lt;pre&gt;------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev _______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
&lt;/pre&gt;</description>
    <dc:creator>Burke Sean</dc:creator>
    <dc:date>2010-08-09T06:19:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2389">
    <title>libpng-1.4.2 is available</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2389</link>
    <description>&lt;pre&gt;libpng-1.4.2 is available from
ftp://ftp.simplesystems.org/pub/png/src
and from
http://libpng.sf.net/index.html

This is a minor cleanup version.  A new "vstudio" project
is supplied, to replace the "visualc6" and "visualc71"
projects, which will be removed from libpng-1.5.0.

The "png_check_sig()" macro is restored, as an
aid to migration from version 1.2.X.

The png_set_dither() function is restored, but renamed
"png_set_quantize()" to reflect more accurately what it
actually does.

For the remainder of 2010, version 1.2.43 will receive only
security updates.  Version 1.0.53 will not receive any
updates from now on.

Glenn

------------------------------------------------------------------------------
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2010-05-06T11:14:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2381">
    <title>handling of too-fast requested framing rates inanimations</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2381</link>
    <description>&lt;pre&gt;Neither the APNG or MNG spec has much to say about how to
handle a situation where the requested framing delay is too
short because either the decoder can't decode the complete
frame in time or because the hardware has a maximum
framing interval that is less than the requested one.

There is a bug report about Firefox not handling requested
framing delays of 1, 2, ..., 10 ms properly.  They seem
slower than a requested 11ms framing delay.

I wondered how the reporter could tell exactly what
is happening if a typical 75Hz monitor was being used
to display the result.

Firefox/Mozilla resets the delay to 100ms if the decoder
isn't finished in time, so I suspect that for the particular
file it takes about 10 ms to decode each frame, so the
framing interval becomes 110ms which would be observably
slower.

I'm recommending that Firefox/Mozilla extend the
delay by 13ms instead of 100ms, which corresponds
to one refresh cycle on a 75Hz monitor.

Glenn

---------------------------------------------------------------&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2009-12-30T18:17:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2379">
    <title>Burn All GIFs Day</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2379</link>
    <description>&lt;pre&gt;Today is the 10th anniversary of Burn All GIFs Day.

Glenn

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2009-11-05T23:51:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2378">
    <title>FW: pnggccrd.c and pngvcrd.c</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2378</link>
    <description>&lt;pre&gt;These two files appear in 1.2.40beta92 but are zero length.

Shouldn't they just be removed?

John Bowler &amp;lt;jbowler-HInyCGIudOg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
&lt;/pre&gt;</description>
    <dc:creator>John Bowler</dc:creator>
    <dc:date>2009-11-05T23:14:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2372">
    <title>MNG and Synchronisation</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2372</link>
    <description>&lt;pre&gt;I have tried to use animated GIFs to solve a specific
programming task in my user interface. However, I am not able to achieve what
at I want with GIFs. The problem is if I put two similar GIFs next to each other,
after some time, they are not any longer synchronised. I need them to be. So my 
question is, will animated MNG files behave better in this respect ?
I am working in Win32 environments.
Please reply directly to me also, since I am not receiving this list.
Martin


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
&lt;/pre&gt;</description>
    <dc:creator>Martin Plassen</dc:creator>
    <dc:date>2009-10-13T06:57:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2371">
    <title>Proposed "XML:com.adobe.xmp" PNG keyword</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2371</link>
    <description>&lt;pre&gt;

Looks good to me.  Let's get libpng-1.4.0 out before voting on
this, though, because the current libpng does not support
iTXt by default, and you cannot even enable it without
manually editing pngconf.h.

I'll publish libpng-1.4.0rc01 very shortly, maybe later on
this week.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2009-10-09T11:32:57</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.graphics.png.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.graphics.png.general</link>
  </textinput>
</rdf:RDF>

