Glad to see people working on this! I already have a functioning almost-pure Swift PNG library <https://github.com/kelvin13/maxpng>, and a JPEG library <https://github.com/kelvin13/jpeg> is a month or two away. I’m glad someone is hacking away at some sort of rasterization engine (like cairo for C/C++). The way I see a lot of these graphics libraries is they live in a sort of “tech tree” and a lot of them depend on support higher up the tree, like in a video game. For now we seem to be filling in a lot of the top row with C libraries which doesn’t always work too well (like in the case of zlib).
Rasterizer File I/O, path manipulation ——————+——— LZ77 compression [{cairo equiv.}] [{file manager lib}, URL <https://github.com/kelvin13/url>] | [{zlib equiv.}] | | | | +—————————+——————————+————————————+ +——————————————+ | | | | | | | | XML HTML TTF/OTF JPEG PNG GZIP | [swiftxml <https://github.com/kelvin13/swiftxml>] [{???}] [{???}] [JPEG <https://github.com/kelvin13/jpeg>] [MaxPNG <https://github.com/kelvin13/maxpng>] [{archiving lib}] | | | | +————————|———————————————+—————+———————————————————+————————————————+ +——+—————+ | | | | | SVG Text renderer WOFF [{???}] [{freetype equiv.}] [{???}] On Thu, Nov 9, 2017 at 9:25 AM, Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > Sound great! > > Last week I started working on a pure-swift graphics library, one goal > being fast server-side graphics manipulations, and already have .png > decode/encode, and quadratic bezier curve stroking implemented, slowly, and > poorly. I’m working on TrueType fonts right now, and intend to open it to > other developers once the basic architecture is refined. I intend to add > SVG and JPEG support as well. It seems like if there is a “swift-community > blessed geometry library”, this would be a natural extension of that, or at > least depend on it. > > Much of this depends on compression support, which I’ve already published > a first cut of at https://github.com/benspratling4/ > SwiftFoundationCompression . The goal there was a more “foundation” idea > of compression than competing libraries, but it suffers from a lack of > streaming support. > > I would absolutely love a “BigNum” library. Several encryption packages > out there would benefit from it as well. It seems arithmetic compression > libraries would benefit, too. Other useful Numeric types would include > rational fractions, fixed-point, and short floats (Float16 is what Apple > now thinks the future of images is, right?). I’m happy to contribute; I > end up writing those in a new language ever few years anyway. > > -Ben Spratling > > > On Nov 7, 2017, at 12:54 PM, Dave DeLong via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi Swift-Evolution, > ... > > We propose to create an open-sourced "Non-Standard Library" effort that > coexists with, coordinates with, and is blessed by the open source Swift > development community. The "Non-Standard Library" will offer a > well-curated, high-value collection of routines, types, and documentation > to support Swift development on all platforms. > … > > > *Suggested Libraries* > > There are several areas we think that are ripe for improvement and > implementation as a non-standard library, such as (but not limited to): > > - A BigNum library > - A full-featured Random library > - A simplified date/time library > - A library for manipulating paths (that is not based on URL or String) > - An expanded Swift-native Geometry library and so forth. > > The scope and extent of the sublibraries would be proposed and debated on > a parallel Non-Standard Library Evolution development list. > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution