[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/7e363edc/attachment.html>