And it's been updated as per suggestion, thanks for the tip.
On 2012-06-11, at 01:45 , Baishampayan Ghose wrote:
>
> > On Sun, Jun 10, 2012 at 10:16 PM, Dmitri
> wrote:
> >> The reason I'm using strings for values is to make it easier to work
> with
> >> deserialized JSON. Currently I have
That's a good point, it would make the API more idiomatic I suppose.
On 2012-06-11, at 01:45 , Baishampayan Ghose wrote:
> On Sun, Jun 10, 2012 at 10:16 PM, Dmitri wrote:
>> The reason I'm using strings for values is to make it easier to work with
>> deserialized JSON. Currently I have it runnin
On Sun, Jun 10, 2012 at 10:16 PM, Dmitri wrote:
> The reason I'm using strings for values is to make it easier to work with
> deserialized JSON. Currently I have it running as a service that our
> internal applications send a JSON request and get a PDF document back.
Internally you can call `name
The reason I'm using strings for values is to make it easier to work with
deserialized JSON. Currently I have it running as a service that our
internal applications send a JSON request and get a PDF document back.
On Sunday, June 10, 2012 12:25:39 PM UTC-4, Moritz Ulrich wrote:
>
> Looks cool!
Looks cool! Unfortunately I currently don't have the time to have a
deep look at it. However, I have a small comment on the api: Many
parameters like 'style', 'size', 'orientation', etc. use strings for
their values. I think keywords would be a better fit there.
On Sun, Jun 10, 2012 at 5:59 PM, Dm
The goal of clj-pdf is to provide a straight forward way to generate PDFs
using markup similar to hiccup. It tries to do the right thing by default,
so all styling hints are optional. It's getting some production use at the
moment, and there don't appear to be any issues so far.
https://github