ErlGuten

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

ErlGuten

Theepan

Hi Team,

I see many forks of ErlGuten. Which one is the latest, most stable and widely used?


Best,
Theepan



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Lloyd R. Prentice-2
Hi Thepan,
 
I’ve undertaken a major revision of ErlGuten called erlPress_core— announced it on Erlang questions several weeks ago.  It’s available from GitHub as Writersglen/erlPress_core. I think you’ll find it much more accessible than the ErlGutens.

I’ve since been polishing up the code and adding a few new features. After the launch I learned that camel case is not conventional usage when it comes to the names of Erlang applications and libraries. So I plan to release the updated version as erlpress_core. With smooth sailing I hope to release sometime this week or next.

All the best,

Lloyd

Sent from my iPad

On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:


Hi Team,

I see many forks of ErlGuten. Which one is the latest, most stable and widely used?


Best,
Theepan


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Theepan
Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]> wrote:
Hi Thepan,
 
I’ve undertaken a major revision of ErlGuten called erlPress_core— announced it on Erlang questions several weeks ago.  It’s available from GitHub as Writersglen/erlPress_core. I think you’ll find it much more accessible than the ErlGutens.

I’ve since been polishing up the code and adding a few new features. After the launch I learned that camel case is not conventional usage when it comes to the names of Erlang applications and libraries. So I plan to release the updated version as erlpress_core. With smooth sailing I hope to release sometime this week or next.

All the best,

Lloyd

Sent from my iPad

On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:


Hi Team,

I see many forks of ErlGuten. Which one is the latest, most stable and widely used?


Best,
Theepan


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Lloyd R. Prentice-2
Hi Theepan,

1. If you look at ErlGuten source, you'll see that function documentation is fairly minimal and many parameters have single character names with little to no documentation. This makes maintenance and revision very difficult. I consider the core ErlGuten modules diamonds-in-the-rough.

I also found the high-level page make-up functions provided by Hugh and Carl limited with respect to professional page make-up and, to me at least, a bit confusing.

But erlpress_core owes a deep debt and much gratitude to the ErlGuten lineage.

erlpress_core is based on Joe's font-handling, justification, and XML parsing code with few if any changes. But it provides map structures to represent nearly all of the PDF objects represented in eg_pdf_op.erl. These map structures incorporate many default parameters so generating PDF documents is syntactically simple and consistent without sacrificing expressive flexibility. You can easily customize display by instantiating map parameters with your own values.

You can see most of the PDF objects currently supported by erlpress_core, including boxed text, justification options, and various line and text objects, demonstrated in ep_show_n_tell.pdf and the source in ep_show_n_tell.erl.

If you look at the map definitions of the various PDF objects, you'll see how to customize display.

At some point if would be good to re-write the base Erlguten modules with more explicit function and parameter documentation, but I'm not up to that at this point. But, anyone looking for a challenge is free to jump in.

I'm currently working on tables and text flow across pages (think reports and book chapters). Hope to deliver these features plus much code polishing in the next release coming "real soon now."

High on my wish/to-do list are:

-- Easy-to_use page-grid design functions
-- Imposition (printing multiple page impressions on a single sheet of paper stock)
-- Articles and beads (think text jumping across  columns and pages)
-- Easy-to-use and expressive page make-up functions
-- Example templates for various print formats
-- Markdown input
-- Support of TTF and OTF fonts

Joe Armstrong expressed the following goal when he first announced ErlGuten:

"Better than TeX."

That's a tall order, yet to be realized. My hope is that erlpress will move the ball further down the field.

2. I haven't done anything with image formats beyond what you'll find in eg_pdf_image.erl. I'd welcome work in that direction.

3. erlpress_core is still at Version 0.01. It's just out. I'm working toward sufficient functionality and stability to support a web application that we have currently under development.

4. I developed erlpress_core on Erlang/OTP 19. It does require support for maps.

I see the erlpress_core library as a valuable library for embedding PDF generation into Erlang applications and as the basis for many exciting Erlang-based print production tools.

So, Treepan, I appreciate your interest and would welcome your involvement in testing and feature development.

I would jump for joy if some Erlang guru were to step forward take on the TTF/OTF support issue. I've done some research and have a few ideas on how expanded font support might be accomplished, but have too little time over the next several months to dig into it.

Incidentally, in my previous post my iPad decided it was smarter than me and erroneously corrected my GitHUb address.it should be writersglen/erlPress_core.

My intention is to bag the camel case in my next release with luck in a week or two so it should look like writersglen/erlpress_core.

All the best,

Lloyd
   

-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 3:59pm
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you
improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high
throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
wrote:

> Hi Thepan,
>
> I’ve undertaken a major revision of ErlGuten called erlPress_core—
> announced it on Erlang questions several weeks ago.  It’s available from
> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> accessible than the ErlGutens.
>
> I’ve since been polishing up the code and adding a few new features. After
> the launch I learned that camel case is not conventional usage when it
> comes to the names of Erlang applications and libraries. So I plan to
> release the updated version as erlpress_core. With smooth sailing I hope to
> release sometime this week or next.
>
> All the best,
>
> Lloyd
>
> Sent from my iPad
>
> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>
>
> Hi Team,
>
> I see many forks of ErlGuten. Which one is the latest, most stable and
> widely used?
>
> https://github.com/richcarl/erlguten
> https://github.com/CarlWright/NGerlguten
> https://github.com/hwatkins/erlguten/commits/master
>
> Best,
> Theepan
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Theepan
Thanks Lloyd for your detailed explanation on what has been done, and your vision for the library. However we are already using ErlGuten in one of our production systems, and the issues is mainly with the images.

I will definitely keep an eye on the development of erlpress_core in the future, as you seem enthusiastic about making it a lively library.

The issues we have are: 

** When some JPEG image is embedded into the PDF, it turns out dark in the generated PDF file
** When some PNG file is embedded, it takes too long (unto 5 minutes) to generate the PDF file. Debugging shows that the delay is on defilter(Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.

Did you come acrsoss this?

Best,
Theepan





On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
Hi Theepan,

1. If you look at ErlGuten source, you'll see that function documentation is fairly minimal and many parameters have single character names with little to no documentation. This makes maintenance and revision very difficult. I consider the core ErlGuten modules diamonds-in-the-rough.

I also found the high-level page make-up functions provided by Hugh and Carl limited with respect to professional page make-up and, to me at least, a bit confusing.

But erlpress_core owes a deep debt and much gratitude to the ErlGuten lineage.

erlpress_core is based on Joe's font-handling, justification, and XML parsing code with few if any changes. But it provides map structures to represent nearly all of the PDF objects represented in eg_pdf_op.erl. These map structures incorporate many default parameters so generating PDF documents is syntactically simple and consistent without sacrificing expressive flexibility. You can easily customize display by instantiating map parameters with your own values.

You can see most of the PDF objects currently supported by erlpress_core, including boxed text, justification options, and various line and text objects, demonstrated in ep_show_n_tell.pdf and the source in ep_show_n_tell.erl.

If you look at the map definitions of the various PDF objects, you'll see how to customize display.

At some point if would be good to re-write the base Erlguten modules with more explicit function and parameter documentation, but I'm not up to that at this point. But, anyone looking for a challenge is free to jump in.

I'm currently working on tables and text flow across pages (think reports and book chapters). Hope to deliver these features plus much code polishing in the next release coming "real soon now."

High on my wish/to-do list are:

-- Easy-to_use page-grid design functions
-- Imposition (printing multiple page impressions on a single sheet of paper stock)
-- Articles and beads (think text jumping across  columns and pages)
-- Easy-to-use and expressive page make-up functions
-- Example templates for various print formats
-- Markdown input
-- Support of TTF and OTF fonts

Joe Armstrong expressed the following goal when he first announced ErlGuten:

"Better than TeX."

That's a tall order, yet to be realized. My hope is that erlpress will move the ball further down the field.

2. I haven't done anything with image formats beyond what you'll find in eg_pdf_image.erl. I'd welcome work in that direction.

3. erlpress_core is still at Version 0.01. It's just out. I'm working toward sufficient functionality and stability to support a web application that we have currently under development.

4. I developed erlpress_core on Erlang/OTP 19. It does require support for maps.

I see the erlpress_core library as a valuable library for embedding PDF generation into Erlang applications and as the basis for many exciting Erlang-based print production tools.

So, Treepan, I appreciate your interest and would welcome your involvement in testing and feature development.

I would jump for joy if some Erlang guru were to step forward take on the TTF/OTF support issue. I've done some research and have a few ideas on how expanded font support might be accomplished, but have too little time over the next several months to dig into it.

Incidentally, in my previous post my iPad decided it was smarter than me and erroneously corrected my GitHUb address.it should be writersglen/erlPress_core.

My intention is to bag the camel case in my next release with luck in a week or two so it should look like writersglen/erlpress_core.

All the best,

Lloyd


-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 3:59pm
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you
improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high
throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
wrote:

> Hi Thepan,
>
> I’ve undertaken a major revision of ErlGuten called erlPress_core—
> announced it on Erlang questions several weeks ago.  It’s available from
> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> accessible than the ErlGutens.
>
> I’ve since been polishing up the code and adding a few new features. After
> the launch I learned that camel case is not conventional usage when it
> comes to the names of Erlang applications and libraries. So I plan to
> release the updated version as erlpress_core. With smooth sailing I hope to
> release sometime this week or next.
>
> All the best,
>
> Lloyd
>
> Sent from my iPad
>
> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>
>
> Hi Team,
>
> I see many forks of ErlGuten. Which one is the latest, most stable and
> widely used?
>
> https://github.com/richcarl/erlguten
> https://github.com/CarlWright/NGerlguten
> https://github.com/hwatkins/erlguten/commits/master
>
> Best,
> Theepan
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Theepan
Wanted to add to the issues the reasons --

** When some JPEG image is embedded into the PDF, it turns out dark in the generated PDF file [Happens due to CYMK color profile.]
** When some PNG file is embedded, it takes too long (unto 5 minutes) to generate the PDF file. Debugging shows that the delay is on defilter(MethodLine1Line2OffsetWidthIter) of eg_pdf_image module.[Happens due to Alpha channel presence]



On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:
Thanks Lloyd for your detailed explanation on what has been done, and your vision for the library. However we are already using ErlGuten in one of our production systems, and the issues is mainly with the images.

I will definitely keep an eye on the development of erlpress_core in the future, as you seem enthusiastic about making it a lively library.

The issues we have are: 

** When some JPEG image is embedded into the PDF, it turns out dark in the generated PDF file
** When some PNG file is embedded, it takes too long (unto 5 minutes) to generate the PDF file. Debugging shows that the delay is on defilter(Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.

Did you come acrsoss this?

Best,
Theepan





On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
Hi Theepan,

1. If you look at ErlGuten source, you'll see that function documentation is fairly minimal and many parameters have single character names with little to no documentation. This makes maintenance and revision very difficult. I consider the core ErlGuten modules diamonds-in-the-rough.

I also found the high-level page make-up functions provided by Hugh and Carl limited with respect to professional page make-up and, to me at least, a bit confusing.

But erlpress_core owes a deep debt and much gratitude to the ErlGuten lineage.

erlpress_core is based on Joe's font-handling, justification, and XML parsing code with few if any changes. But it provides map structures to represent nearly all of the PDF objects represented in eg_pdf_op.erl. These map structures incorporate many default parameters so generating PDF documents is syntactically simple and consistent without sacrificing expressive flexibility. You can easily customize display by instantiating map parameters with your own values.

You can see most of the PDF objects currently supported by erlpress_core, including boxed text, justification options, and various line and text objects, demonstrated in ep_show_n_tell.pdf and the source in ep_show_n_tell.erl.

If you look at the map definitions of the various PDF objects, you'll see how to customize display.

At some point if would be good to re-write the base Erlguten modules with more explicit function and parameter documentation, but I'm not up to that at this point. But, anyone looking for a challenge is free to jump in.

I'm currently working on tables and text flow across pages (think reports and book chapters). Hope to deliver these features plus much code polishing in the next release coming "real soon now."

High on my wish/to-do list are:

-- Easy-to_use page-grid design functions
-- Imposition (printing multiple page impressions on a single sheet of paper stock)
-- Articles and beads (think text jumping across  columns and pages)
-- Easy-to-use and expressive page make-up functions
-- Example templates for various print formats
-- Markdown input
-- Support of TTF and OTF fonts

Joe Armstrong expressed the following goal when he first announced ErlGuten:

"Better than TeX."

That's a tall order, yet to be realized. My hope is that erlpress will move the ball further down the field.

2. I haven't done anything with image formats beyond what you'll find in eg_pdf_image.erl. I'd welcome work in that direction.

3. erlpress_core is still at Version 0.01. It's just out. I'm working toward sufficient functionality and stability to support a web application that we have currently under development.

4. I developed erlpress_core on Erlang/OTP 19. It does require support for maps.

I see the erlpress_core library as a valuable library for embedding PDF generation into Erlang applications and as the basis for many exciting Erlang-based print production tools.

So, Treepan, I appreciate your interest and would welcome your involvement in testing and feature development.

I would jump for joy if some Erlang guru were to step forward take on the TTF/OTF support issue. I've done some research and have a few ideas on how expanded font support might be accomplished, but have too little time over the next several months to dig into it.

Incidentally, in my previous post my iPad decided it was smarter than me and erroneously corrected my GitHUb address.it should be writersglen/erlPress_core.

My intention is to bag the camel case in my next release with luck in a week or two so it should look like writersglen/erlpress_core.

All the best,

Lloyd


-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 3:59pm
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you
improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high
throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
wrote:

> Hi Thepan,
>
> I’ve undertaken a major revision of ErlGuten called erlPress_core—
> announced it on Erlang questions several weeks ago.  It’s available from
> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> accessible than the ErlGutens.
>
> I’ve since been polishing up the code and adding a few new features. After
> the launch I learned that camel case is not conventional usage when it
> comes to the names of Erlang applications and libraries. So I plan to
> release the updated version as erlpress_core. With smooth sailing I hope to
> release sometime this week or next.
>
> All the best,
>
> Lloyd
>
> Sent from my iPad
>
> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>
>
> Hi Team,
>
> I see many forks of ErlGuten. Which one is the latest, most stable and
> widely used?
>
> https://github.com/richcarl/erlguten
> https://github.com/CarlWright/NGerlguten
> https://github.com/hwatkins/erlguten/commits/master
>
> Best,
> Theepan
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Sean Hinde-4
In reply to this post by Theepan
I hit the same issue. I guess you are using one of the versions with lots of lists:nth.

Following find my patch on the version I was using.

You can find my branch at:


No time right now to make nice pull requests - I will eventually

===============================================

diff --git a/src/eg_pdf_image.erl b/src/eg_pdf_image.erl
index 1a97e0b..817f1b8 100644
--- a/src/eg_pdf_image.erl
+++ b/src/eg_pdf_image.erl
@@ -431,11 +431,11 @@ extractScanLines(Width,Decompressed) ->

 extractLine(ScanLines,Width,<< >>) ->
   AlmostDone = lists:reverse(ScanLines),
-  [ {0, string:chars(0,Width-1)} | AlmostDone];
+  [ {0, list_to_binary(string:chars(0,Width-1))} | AlmostDone];
 extractLine(ScanLines,Width,Image) ->
   LineSize = Width - 1,
   << Method:8, Line:LineSize/binary-unit:8, Rest/binary>> = Image,
-  extractLine([{Method,  binary_to_list(Line) } | ScanLines ], Width, Rest).
+  extractLine([{Method,  Line} | ScanLines ], Width, Rest).

 %% @doc Remove the filter on all the bytes in the scan lines.

@@ -448,19 +448,26 @@ processLine([{_Method, _Line1}], _Iter, _Offset, Results)->
    A = lists:flatten( lists:reverse(Results) ),
    list_to_binary( A );
 processLine([{_, Line1},{Method, Line2} | Remainder], Iter, Offset, Results) ->
-  {ok, Unfiltered} = defilter(Method, Line1, Line2,Offset,length(Line1),Iter),
+  {ok, Unfiltered} = defilter(Method, Line1, Line2,Offset,size(Line1),Iter),
   processLine([{Method, Unfiltered } | Remainder], Iter, Offset, [Unfiltered | Results] ).

 %% @doc Taking two lines of stream defilter the 2nd with the previously defiltered 1st line.

 defilter(Method, Line1, Line2, Offset, Width, Iter) when Iter =< Width ->
   NewVal = case Iter =< Offset of
-    true ->  filter(lists:nth(Iter,Line2), 0, lists:nth(Iter,Line1), 0, Method);
-    false ->  filter(lists:nth(Iter,Line2), lists:nth(Iter-Offset,Line2), lists:nth(Iter,Line1), lists:nth(Iter-Offset,Line1), Method)
+    true ->  filter(binary:at(Line2, Iter - 1), 0,
+                    binary:at(Line1, Iter - 1), 0, Method);
+    false ->  filter(binary:at(Line2, Iter - 1),
+                     binary:at(Line2, Iter - Offset - 1),
+                     binary:at(Line1, Iter - 1),
+                     binary:at(Line1, Iter - Offset - 1), Method)
     end,
     L2 = case Iter == Width of
-      true -> lists:flatten([lists:sublist(Line2,Iter - 1),NewVal]);
-      false -> lists:flatten([lists:sublist(Line2,Iter - 1),NewVal,lists:nthtail(Iter, Line2)])
+      true -> Start = binary:part(Line2, 0, Iter - 1),
+              <<Start/binary, NewVal>>;
+      false -> Start = binary:part(Line2, 0, Iter - 1),
+               End = binary:part(Line2, Iter, size(Line2) - Iter),
+               <<Start/binary, NewVal, End/binary>>
     end,
     defilter(Method, Line1, L2 ,Offset, Width, Iter+1);
 defilter(_Method, _Line1, Line2, _Offset, _Width, _Iter) ->
@@ -513,8 +520,7 @@ inflate_stream(Data) ->
   Decompressed = zlib:inflate(Z, Data),
   ok = zlib:inflateEnd(Z),
   zlib:close(Z),
-  F = fun(A, B) -> <<A/binary, B/binary>> end,
-  MergedBinaries = lists:foldr(F, <<>>, Decompressed),
+  MergedBinaries = iolist_to_binary(Decompressed),
   {ok,MergedBinaries}.

 %% @doc Compress a bit stream using the zlib/deflate algorithm

===============================================

On 25 Sep 2018, at 01:15, Theepan <[hidden email]> wrote:

Thanks Lloyd for your detailed explanation on what has been done, and your vision for the library. However we are already using ErlGuten in one of our production systems, and the issues is mainly with the images.

I will definitely keep an eye on the development of erlpress_core in the future, as you seem enthusiastic about making it a lively library.

The issues we have are: 

** When some JPEG image is embedded into the PDF, it turns out dark in the generated PDF file
** When some PNG file is embedded, it takes too long (unto 5 minutes) to generate the PDF file. Debugging shows that the delay is on defilter(Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.

Did you come acrsoss this?

Best,
Theepan





On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
Hi Theepan,

1. If you look at ErlGuten source, you'll see that function documentation is fairly minimal and many parameters have single character names with little to no documentation. This makes maintenance and revision very difficult. I consider the core ErlGuten modules diamonds-in-the-rough.

I also found the high-level page make-up functions provided by Hugh and Carl limited with respect to professional page make-up and, to me at least, a bit confusing.

But erlpress_core owes a deep debt and much gratitude to the ErlGuten lineage.

erlpress_core is based on Joe's font-handling, justification, and XML parsing code with few if any changes. But it provides map structures to represent nearly all of the PDF objects represented in eg_pdf_op.erl. These map structures incorporate many default parameters so generating PDF documents is syntactically simple and consistent without sacrificing expressive flexibility. You can easily customize display by instantiating map parameters with your own values.

You can see most of the PDF objects currently supported by erlpress_core, including boxed text, justification options, and various line and text objects, demonstrated in ep_show_n_tell.pdf and the source in ep_show_n_tell.erl.

If you look at the map definitions of the various PDF objects, you'll see how to customize display.

At some point if would be good to re-write the base Erlguten modules with more explicit function and parameter documentation, but I'm not up to that at this point. But, anyone looking for a challenge is free to jump in.

I'm currently working on tables and text flow across pages (think reports and book chapters). Hope to deliver these features plus much code polishing in the next release coming "real soon now."

High on my wish/to-do list are:

-- Easy-to_use page-grid design functions
-- Imposition (printing multiple page impressions on a single sheet of paper stock)
-- Articles and beads (think text jumping across  columns and pages)
-- Easy-to-use and expressive page make-up functions
-- Example templates for various print formats
-- Markdown input
-- Support of TTF and OTF fonts

Joe Armstrong expressed the following goal when he first announced ErlGuten:

"Better than TeX."

That's a tall order, yet to be realized. My hope is that erlpress will move the ball further down the field.

2. I haven't done anything with image formats beyond what you'll find in eg_pdf_image.erl. I'd welcome work in that direction.

3. erlpress_core is still at Version 0.01. It's just out. I'm working toward sufficient functionality and stability to support a web application that we have currently under development.

4. I developed erlpress_core on Erlang/OTP 19. It does require support for maps.

I see the erlpress_core library as a valuable library for embedding PDF generation into Erlang applications and as the basis for many exciting Erlang-based print production tools.

So, Treepan, I appreciate your interest and would welcome your involvement in testing and feature development.

I would jump for joy if some Erlang guru were to step forward take on the TTF/OTF support issue. I've done some research and have a few ideas on how expanded font support might be accomplished, but have too little time over the next several months to dig into it.

Incidentally, in my previous post my iPad decided it was smarter than me and erroneously corrected my GitHUb address.it should be writersglen/erlPress_core.

My intention is to bag the camel case in my next release with luck in a week or two so it should look like writersglen/erlpress_core.

All the best,

Lloyd


-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 3:59pm
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you
improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high
throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
wrote:

> Hi Thepan,
>
> I’ve undertaken a major revision of ErlGuten called erlPress_core—
> announced it on Erlang questions several weeks ago.  It’s available from
> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> accessible than the ErlGutens.
>
> I’ve since been polishing up the code and adding a few new features. After
> the launch I learned that camel case is not conventional usage when it
> comes to the names of Erlang applications and libraries. So I plan to
> release the updated version as erlpress_core. With smooth sailing I hope to
> release sometime this week or next.
>
> All the best,
>
> Lloyd
>
> Sent from my iPad
>
> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>
>
> Hi Team,
>
> I see many forks of ErlGuten. Which one is the latest, most stable and
> widely used?
>
> https://github.com/richcarl/erlguten
> https://github.com/CarlWright/NGerlguten
> https://github.com/hwatkins/erlguten/commits/master
>
> Best,
> Theepan
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Lloyd R. Prentice-2
In reply to this post by Theepan
Hi Theepan,

Other than display in my demo PDF, I haven't worked much with images.

The issues you've run across seem serious. Getting at the root of the problems will likely involve a deep dive into both the PDF reference manuals and core ErlGuten source code.

As I noted in my earlier email, ErlGuten source code is very challenging. It would benefit significantly from re-write, possibly refactoring in some cases and definitely systematic documentation of functions and parameters.

I'm not confident that my skills are up to this. My take is that it would require some amount of community effort to put ErlGuten/erlpress_core on a solid, maintainable base. I would dearly love to see this happen.

Is there a CS major or intern out there with time to take on the challenges?

Joe showed us the way and I, for one, am deeply grateful. Given that PDF is a significant standard in the print media world, Erlang deserves to have a world-class library and suite of tools to generate PDF documents and decode them back into Erlang structures.

This will take community effort.

All the best,

Lloyd

 



-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 7:27pm
To: "Lloyd Prentice" <[hidden email]>
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Wanted to add to the issues the reasons --

** When some JPEG image is embedded into the PDF, it turns out dark in the
generated PDF file [Happens due to CYMK color profile.]
** When some PNG file is embedded, it takes too long (unto 5 minutes) to
generate the PDF file. Debugging shows that the delay is on defilter(Method
, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
Alpha channel presence]



On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:

> Thanks Lloyd for your detailed explanation on what has been done, and your
> vision for the library. However we are already using ErlGuten in one of our
> production systems, and the issues is mainly with the images.
>
> I will definitely keep an eye on the development of erlpress_core in the
> future, as you seem enthusiastic about making it a lively library.
>
> The issues we have are:
>
> ** When some JPEG image is embedded into the PDF, it turns out dark in the
> generated PDF file
> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> generate the PDF file. Debugging shows that the delay is on defilter(
> Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
>
> Did you come acrsoss this?
>
> Best,
> Theepan
>
>
>
>
>
> On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
>
>> Hi Theepan,
>>
>> 1. If you look at ErlGuten source, you'll see that function documentation
>> is fairly minimal and many parameters have single character names with
>> little to no documentation. This makes maintenance and revision very
>> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
>>
>> I also found the high-level page make-up functions provided by Hugh and
>> Carl limited with respect to professional page make-up and, to me at least,
>> a bit confusing.
>>
>> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
>> lineage.
>>
>> erlpress_core is based on Joe's font-handling, justification, and XML
>> parsing code with few if any changes. But it provides map structures to
>> represent nearly all of the PDF objects represented in eg_pdf_op.erl. These
>> map structures incorporate many default parameters so generating PDF
>> documents is syntactically simple and consistent without sacrificing
>> expressive flexibility. You can easily customize display by instantiating
>> map parameters with your own values.
>>
>> You can see most of the PDF objects currently supported by erlpress_core,
>> including boxed text, justification options, and various line and text
>> objects, demonstrated in ep_show_n_tell.pdf and the source in
>> ep_show_n_tell.erl.
>>
>> If you look at the map definitions of the various PDF objects, you'll see
>> how to customize display.
>>
>> At some point if would be good to re-write the base Erlguten modules with
>> more explicit function and parameter documentation, but I'm not up to that
>> at this point. But, anyone looking for a challenge is free to jump in.
>>
>> I'm currently working on tables and text flow across pages (think reports
>> and book chapters). Hope to deliver these features plus much code polishing
>> in the next release coming "real soon now."
>>
>> High on my wish/to-do list are:
>>
>> -- Easy-to_use page-grid design functions
>> -- Imposition (printing multiple page impressions on a single sheet of
>> paper stock)
>> -- Articles and beads (think text jumping across  columns and pages)
>> -- Easy-to-use and expressive page make-up functions
>> -- Example templates for various print formats
>> -- Markdown input
>> -- Support of TTF and OTF fonts
>>
>> Joe Armstrong expressed the following goal when he first announced
>> ErlGuten:
>>
>> "Better than TeX."
>>
>> That's a tall order, yet to be realized. My hope is that erlpress will
>> move the ball further down the field.
>>
>> 2. I haven't done anything with image formats beyond what you'll find in
>> eg_pdf_image.erl. I'd welcome work in that direction.
>>
>> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
>> toward sufficient functionality and stability to support a web application
>> that we have currently under development.
>>
>> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
>> for maps.
>>
>> I see the erlpress_core library as a valuable library for embedding PDF
>> generation into Erlang applications and as the basis for many exciting
>> Erlang-based print production tools.
>>
>> So, Treepan, I appreciate your interest and would welcome your
>> involvement in testing and feature development.
>>
>> I would jump for joy if some Erlang guru were to step forward take on the
>> TTF/OTF support issue. I've done some research and have a few ideas on how
>> expanded font support might be accomplished, but have too little time over
>> the next several months to dig into it.
>>
>> Incidentally, in my previous post my iPad decided it was smarter than me
>> and erroneously corrected my GitHUb address.it should be
>> writersglen/erlPress_core.
>>
>> My intention is to bag the camel case in my next release with luck in a
>> week or two so it should look like writersglen/erlpress_core.
>>
>> All the best,
>>
>> Lloyd
>>
>>
>> -----Original Message-----
>> From: "Theepan" <[hidden email]>
>> Sent: Monday, September 24, 2018 3:59pm
>> To: [hidden email]
>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>> Armstrong" <[hidden email]>
>> Subject: Re: [erlang-questions] ErlGuten
>>
>> Hi Lloyd,
>>
>> Thank you for your response. I have some quick clarifications --
>>
>> * What are the major improvements made on the source ErlGuten? Did you
>> improve support to different image formats? Any critical bugs fixed?
>> * Is erlPress_core used in commercial applications, specifically of high
>> throughput types?
>> * What is the minimum erlang/OTP version required?
>>
>> Best,
>> Theepan
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
>> wrote:
>>
>> > Hi Thepan,
>> >
>> > I’ve undertaken a major revision of ErlGuten called erlPress_core—
>> > announced it on Erlang questions several weeks ago.  It’s available from
>> > GitHub as Writersglen/erlPress_core. I think you’ll find it much more
>> > accessible than the ErlGutens.
>> >
>> > I’ve since been polishing up the code and adding a few new features.
>> After
>> > the launch I learned that camel case is not conventional usage when it
>> > comes to the names of Erlang applications and libraries. So I plan to
>> > release the updated version as erlpress_core. With smooth sailing I
>> hope to
>> > release sometime this week or next.
>> >
>> > All the best,
>> >
>> > Lloyd
>> >
>> > Sent from my iPad
>> >
>> > On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>> >
>> >
>> > Hi Team,
>> >
>> > I see many forks of ErlGuten. Which one is the latest, most stable and
>> > widely used?
>> >
>> > https://github.com/richcarl/erlguten
>> > https://github.com/CarlWright/NGerlguten
>> > https://github.com/hwatkins/erlguten/commits/master
>> >
>> > Best,
>> > Theepan
>> >
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > [hidden email]
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> >
>>
>>
>>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Theepan
In reply to this post by Sean Hinde-4
Hi Sean,

I used GraphicsMagic to remove the alpha channel before passing onto ErlGuten. It ensures that the code not taking that inefficient path. It works very well.

I hope ErlGuten needs to be improved for image embedding support and performance using port. Also when the alpha channel is removed, eg_pdg gen_server can be made to work for parallel PDF generation by removing the local name registration.

Best,
Theepan



On Tue, Sep 25, 2018 at 7:50 PM Sean Hinde <[hidden email]> wrote:
I hit the same issue. I guess you are using one of the versions with lots of lists:nth.

Following find my patch on the version I was using.

You can find my branch at:


No time right now to make nice pull requests - I will eventually

===============================================

diff --git a/src/eg_pdf_image.erl b/src/eg_pdf_image.erl
index 1a97e0b..817f1b8 100644
--- a/src/eg_pdf_image.erl
+++ b/src/eg_pdf_image.erl
@@ -431,11 +431,11 @@ extractScanLines(Width,Decompressed) ->

 extractLine(ScanLines,Width,<< >>) ->
   AlmostDone = lists:reverse(ScanLines),
-  [ {0, string:chars(0,Width-1)} | AlmostDone];
+  [ {0, list_to_binary(string:chars(0,Width-1))} | AlmostDone];
 extractLine(ScanLines,Width,Image) ->
   LineSize = Width - 1,
   << Method:8, Line:LineSize/binary-unit:8, Rest/binary>> = Image,
-  extractLine([{Method,  binary_to_list(Line) } | ScanLines ], Width, Rest).
+  extractLine([{Method,  Line} | ScanLines ], Width, Rest).

 %% @doc Remove the filter on all the bytes in the scan lines.

@@ -448,19 +448,26 @@ processLine([{_Method, _Line1}], _Iter, _Offset, Results)->
    A = lists:flatten( lists:reverse(Results) ),
    list_to_binary( A );
 processLine([{_, Line1},{Method, Line2} | Remainder], Iter, Offset, Results) ->
-  {ok, Unfiltered} = defilter(Method, Line1, Line2,Offset,length(Line1),Iter),
+  {ok, Unfiltered} = defilter(Method, Line1, Line2,Offset,size(Line1),Iter),
   processLine([{Method, Unfiltered } | Remainder], Iter, Offset, [Unfiltered | Results] ).

 %% @doc Taking two lines of stream defilter the 2nd with the previously defiltered 1st line.

 defilter(Method, Line1, Line2, Offset, Width, Iter) when Iter =< Width ->
   NewVal = case Iter =< Offset of
-    true ->  filter(lists:nth(Iter,Line2), 0, lists:nth(Iter,Line1), 0, Method);
-    false ->  filter(lists:nth(Iter,Line2), lists:nth(Iter-Offset,Line2), lists:nth(Iter,Line1), lists:nth(Iter-Offset,Line1), Method)
+    true ->  filter(binary:at(Line2, Iter - 1), 0,
+                    binary:at(Line1, Iter - 1), 0, Method);
+    false ->  filter(binary:at(Line2, Iter - 1),
+                     binary:at(Line2, Iter - Offset - 1),
+                     binary:at(Line1, Iter - 1),
+                     binary:at(Line1, Iter - Offset - 1), Method)
     end,
     L2 = case Iter == Width of
-      true -> lists:flatten([lists:sublist(Line2,Iter - 1),NewVal]);
-      false -> lists:flatten([lists:sublist(Line2,Iter - 1),NewVal,lists:nthtail(Iter, Line2)])
+      true -> Start = binary:part(Line2, 0, Iter - 1),
+              <<Start/binary, NewVal>>;
+      false -> Start = binary:part(Line2, 0, Iter - 1),
+               End = binary:part(Line2, Iter, size(Line2) - Iter),
+               <<Start/binary, NewVal, End/binary>>
     end,
     defilter(Method, Line1, L2 ,Offset, Width, Iter+1);
 defilter(_Method, _Line1, Line2, _Offset, _Width, _Iter) ->
@@ -513,8 +520,7 @@ inflate_stream(Data) ->
   Decompressed = zlib:inflate(Z, Data),
   ok = zlib:inflateEnd(Z),
   zlib:close(Z),
-  F = fun(A, B) -> <<A/binary, B/binary>> end,
-  MergedBinaries = lists:foldr(F, <<>>, Decompressed),
+  MergedBinaries = iolist_to_binary(Decompressed),
   {ok,MergedBinaries}.

 %% @doc Compress a bit stream using the zlib/deflate algorithm

===============================================

On 25 Sep 2018, at 01:15, Theepan <[hidden email]> wrote:

Thanks Lloyd for your detailed explanation on what has been done, and your vision for the library. However we are already using ErlGuten in one of our production systems, and the issues is mainly with the images.

I will definitely keep an eye on the development of erlpress_core in the future, as you seem enthusiastic about making it a lively library.

The issues we have are: 

** When some JPEG image is embedded into the PDF, it turns out dark in the generated PDF file
** When some PNG file is embedded, it takes too long (unto 5 minutes) to generate the PDF file. Debugging shows that the delay is on defilter(Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.

Did you come acrsoss this?

Best,
Theepan





On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
Hi Theepan,

1. If you look at ErlGuten source, you'll see that function documentation is fairly minimal and many parameters have single character names with little to no documentation. This makes maintenance and revision very difficult. I consider the core ErlGuten modules diamonds-in-the-rough.

I also found the high-level page make-up functions provided by Hugh and Carl limited with respect to professional page make-up and, to me at least, a bit confusing.

But erlpress_core owes a deep debt and much gratitude to the ErlGuten lineage.

erlpress_core is based on Joe's font-handling, justification, and XML parsing code with few if any changes. But it provides map structures to represent nearly all of the PDF objects represented in eg_pdf_op.erl. These map structures incorporate many default parameters so generating PDF documents is syntactically simple and consistent without sacrificing expressive flexibility. You can easily customize display by instantiating map parameters with your own values.

You can see most of the PDF objects currently supported by erlpress_core, including boxed text, justification options, and various line and text objects, demonstrated in ep_show_n_tell.pdf and the source in ep_show_n_tell.erl.

If you look at the map definitions of the various PDF objects, you'll see how to customize display.

At some point if would be good to re-write the base Erlguten modules with more explicit function and parameter documentation, but I'm not up to that at this point. But, anyone looking for a challenge is free to jump in.

I'm currently working on tables and text flow across pages (think reports and book chapters). Hope to deliver these features plus much code polishing in the next release coming "real soon now."

High on my wish/to-do list are:

-- Easy-to_use page-grid design functions
-- Imposition (printing multiple page impressions on a single sheet of paper stock)
-- Articles and beads (think text jumping across  columns and pages)
-- Easy-to-use and expressive page make-up functions
-- Example templates for various print formats
-- Markdown input
-- Support of TTF and OTF fonts

Joe Armstrong expressed the following goal when he first announced ErlGuten:

"Better than TeX."

That's a tall order, yet to be realized. My hope is that erlpress will move the ball further down the field.

2. I haven't done anything with image formats beyond what you'll find in eg_pdf_image.erl. I'd welcome work in that direction.

3. erlpress_core is still at Version 0.01. It's just out. I'm working toward sufficient functionality and stability to support a web application that we have currently under development.

4. I developed erlpress_core on Erlang/OTP 19. It does require support for maps.

I see the erlpress_core library as a valuable library for embedding PDF generation into Erlang applications and as the basis for many exciting Erlang-based print production tools.

So, Treepan, I appreciate your interest and would welcome your involvement in testing and feature development.

I would jump for joy if some Erlang guru were to step forward take on the TTF/OTF support issue. I've done some research and have a few ideas on how expanded font support might be accomplished, but have too little time over the next several months to dig into it.

Incidentally, in my previous post my iPad decided it was smarter than me and erroneously corrected my GitHUb address.it should be writersglen/erlPress_core.

My intention is to bag the camel case in my next release with luck in a week or two so it should look like writersglen/erlpress_core.

All the best,

Lloyd


-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 3:59pm
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you
improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high
throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
wrote:

> Hi Thepan,
>
> I’ve undertaken a major revision of ErlGuten called erlPress_core—
> announced it on Erlang questions several weeks ago.  It’s available from
> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> accessible than the ErlGutens.
>
> I’ve since been polishing up the code and adding a few new features. After
> the launch I learned that camel case is not conventional usage when it
> comes to the names of Erlang applications and libraries. So I plan to
> release the updated version as erlpress_core. With smooth sailing I hope to
> release sometime this week or next.
>
> All the best,
>
> Lloyd
>
> Sent from my iPad
>
> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>
>
> Hi Team,
>
> I see many forks of ErlGuten. Which one is the latest, most stable and
> widely used?
>
> https://github.com/richcarl/erlguten
> https://github.com/CarlWright/NGerlguten
> https://github.com/hwatkins/erlguten/commits/master
>
> Best,
> Theepan
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Theepan
In reply to this post by Lloyd R. Prentice-2
Hi Lloyd,

You are right. PDF generation library is crucial to most of the commercial applications. The code base is not very complicated, but then again we need somebody who has time and willingness to take on the work. Please find what have written to Sean on what improvements can be crucial short term.

Wish work arounds and short fixes we could achieve the required scemantics, performance and throughput out of ErlGuten.

Best,
Theepan



On Tue, Sep 25, 2018 at 10:21 PM <[hidden email]> wrote:
Hi Theepan,

Other than display in my demo PDF, I haven't worked much with images.

The issues you've run across seem serious. Getting at the root of the problems will likely involve a deep dive into both the PDF reference manuals and core ErlGuten source code.

As I noted in my earlier email, ErlGuten source code is very challenging. It would benefit significantly from re-write, possibly refactoring in some cases and definitely systematic documentation of functions and parameters.

I'm not confident that my skills are up to this. My take is that it would require some amount of community effort to put ErlGuten/erlpress_core on a solid, maintainable base. I would dearly love to see this happen.

Is there a CS major or intern out there with time to take on the challenges?

Joe showed us the way and I, for one, am deeply grateful. Given that PDF is a significant standard in the print media world, Erlang deserves to have a world-class library and suite of tools to generate PDF documents and decode them back into Erlang structures.

This will take community effort.

All the best,

Lloyd





-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 7:27pm
To: "Lloyd Prentice" <[hidden email]>
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Wanted to add to the issues the reasons --

** When some JPEG image is embedded into the PDF, it turns out dark in the
generated PDF file [Happens due to CYMK color profile.]
** When some PNG file is embedded, it takes too long (unto 5 minutes) to
generate the PDF file. Debugging shows that the delay is on defilter(Method
, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
Alpha channel presence]



On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:

> Thanks Lloyd for your detailed explanation on what has been done, and your
> vision for the library. However we are already using ErlGuten in one of our
> production systems, and the issues is mainly with the images.
>
> I will definitely keep an eye on the development of erlpress_core in the
> future, as you seem enthusiastic about making it a lively library.
>
> The issues we have are:
>
> ** When some JPEG image is embedded into the PDF, it turns out dark in the
> generated PDF file
> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> generate the PDF file. Debugging shows that the delay is on defilter(
> Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
>
> Did you come acrsoss this?
>
> Best,
> Theepan
>
>
>
>
>
> On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
>
>> Hi Theepan,
>>
>> 1. If you look at ErlGuten source, you'll see that function documentation
>> is fairly minimal and many parameters have single character names with
>> little to no documentation. This makes maintenance and revision very
>> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
>>
>> I also found the high-level page make-up functions provided by Hugh and
>> Carl limited with respect to professional page make-up and, to me at least,
>> a bit confusing.
>>
>> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
>> lineage.
>>
>> erlpress_core is based on Joe's font-handling, justification, and XML
>> parsing code with few if any changes. But it provides map structures to
>> represent nearly all of the PDF objects represented in eg_pdf_op.erl. These
>> map structures incorporate many default parameters so generating PDF
>> documents is syntactically simple and consistent without sacrificing
>> expressive flexibility. You can easily customize display by instantiating
>> map parameters with your own values.
>>
>> You can see most of the PDF objects currently supported by erlpress_core,
>> including boxed text, justification options, and various line and text
>> objects, demonstrated in ep_show_n_tell.pdf and the source in
>> ep_show_n_tell.erl.
>>
>> If you look at the map definitions of the various PDF objects, you'll see
>> how to customize display.
>>
>> At some point if would be good to re-write the base Erlguten modules with
>> more explicit function and parameter documentation, but I'm not up to that
>> at this point. But, anyone looking for a challenge is free to jump in.
>>
>> I'm currently working on tables and text flow across pages (think reports
>> and book chapters). Hope to deliver these features plus much code polishing
>> in the next release coming "real soon now."
>>
>> High on my wish/to-do list are:
>>
>> -- Easy-to_use page-grid design functions
>> -- Imposition (printing multiple page impressions on a single sheet of
>> paper stock)
>> -- Articles and beads (think text jumping across  columns and pages)
>> -- Easy-to-use and expressive page make-up functions
>> -- Example templates for various print formats
>> -- Markdown input
>> -- Support of TTF and OTF fonts
>>
>> Joe Armstrong expressed the following goal when he first announced
>> ErlGuten:
>>
>> "Better than TeX."
>>
>> That's a tall order, yet to be realized. My hope is that erlpress will
>> move the ball further down the field.
>>
>> 2. I haven't done anything with image formats beyond what you'll find in
>> eg_pdf_image.erl. I'd welcome work in that direction.
>>
>> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
>> toward sufficient functionality and stability to support a web application
>> that we have currently under development.
>>
>> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
>> for maps.
>>
>> I see the erlpress_core library as a valuable library for embedding PDF
>> generation into Erlang applications and as the basis for many exciting
>> Erlang-based print production tools.
>>
>> So, Treepan, I appreciate your interest and would welcome your
>> involvement in testing and feature development.
>>
>> I would jump for joy if some Erlang guru were to step forward take on the
>> TTF/OTF support issue. I've done some research and have a few ideas on how
>> expanded font support might be accomplished, but have too little time over
>> the next several months to dig into it.
>>
>> Incidentally, in my previous post my iPad decided it was smarter than me
>> and erroneously corrected my GitHUb address.it should be
>> writersglen/erlPress_core.
>>
>> My intention is to bag the camel case in my next release with luck in a
>> week or two so it should look like writersglen/erlpress_core.
>>
>> All the best,
>>
>> Lloyd
>>
>>
>> -----Original Message-----
>> From: "Theepan" <[hidden email]>
>> Sent: Monday, September 24, 2018 3:59pm
>> To: [hidden email]
>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>> Armstrong" <[hidden email]>
>> Subject: Re: [erlang-questions] ErlGuten
>>
>> Hi Lloyd,
>>
>> Thank you for your response. I have some quick clarifications --
>>
>> * What are the major improvements made on the source ErlGuten? Did you
>> improve support to different image formats? Any critical bugs fixed?
>> * Is erlPress_core used in commercial applications, specifically of high
>> throughput types?
>> * What is the minimum erlang/OTP version required?
>>
>> Best,
>> Theepan
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
>> wrote:
>>
>> > Hi Thepan,
>> >
>> > I’ve undertaken a major revision of ErlGuten called erlPress_core—
>> > announced it on Erlang questions several weeks ago.  It’s available from
>> > GitHub as Writersglen/erlPress_core. I think you’ll find it much more
>> > accessible than the ErlGutens.
>> >
>> > I’ve since been polishing up the code and adding a few new features.
>> After
>> > the launch I learned that camel case is not conventional usage when it
>> > comes to the names of Erlang applications and libraries. So I plan to
>> > release the updated version as erlpress_core. With smooth sailing I
>> hope to
>> > release sometime this week or next.
>> >
>> > All the best,
>> >
>> > Lloyd
>> >
>> > Sent from my iPad
>> >
>> > On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>> >
>> >
>> > Hi Team,
>> >
>> > I see many forks of ErlGuten. Which one is the latest, most stable and
>> > widely used?
>> >
>> > https://github.com/richcarl/erlguten
>> > https://github.com/CarlWright/NGerlguten
>> > https://github.com/hwatkins/erlguten/commits/master
>> >
>> > Best,
>> > Theepan
>> >
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > [hidden email]
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> >
>>
>>
>>



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten + a short survey

Lloyd R. Prentice-2
Hi folks,

As Theepan says,  "PDF generation library is crucial to most of the commercial
applications."

If you are using ErlGuten, please help inform my work on erlpress_core:

1. What are you using it for?
2. What features do you wish it has but doesn't?

Many thanks,

Lloyd

-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Tuesday, September 25, 2018 2:55pm
To: "Lloyd Prentice" <[hidden email]>
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

You are right. PDF generation library is crucial to most of the commercial
applications. The code base is not very complicated, but then again we need
somebody who has time and willingness to take on the work. Please find what
have written to Sean on what improvements can be crucial short term.

Wish work arounds and short fixes we could achieve the required scemantics,
performance and throughput out of ErlGuten.

Best,
Theepan



On Tue, Sep 25, 2018 at 10:21 PM <[hidden email]> wrote:

> Hi Theepan,
>
> Other than display in my demo PDF, I haven't worked much with images.
>
> The issues you've run across seem serious. Getting at the root of the
> problems will likely involve a deep dive into both the PDF reference
> manuals and core ErlGuten source code.
>
> As I noted in my earlier email, ErlGuten source code is very challenging.
> It would benefit significantly from re-write, possibly refactoring in some
> cases and definitely systematic documentation of functions and parameters.
>
> I'm not confident that my skills are up to this. My take is that it would
> require some amount of community effort to put ErlGuten/erlpress_core on a
> solid, maintainable base. I would dearly love to see this happen.
>
> Is there a CS major or intern out there with time to take on the
> challenges?
>
> Joe showed us the way and I, for one, am deeply grateful. Given that PDF
> is a significant standard in the print media world, Erlang deserves to have
> a world-class library and suite of tools to generate PDF documents and
> decode them back into Erlang structures.
>
> This will take community effort.
>
> All the best,
>
> Lloyd
>
>
>
>
>
> -----Original Message-----
> From: "Theepan" <[hidden email]>
> Sent: Monday, September 24, 2018 7:27pm
> To: "Lloyd Prentice" <[hidden email]>
> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
> Armstrong" <[hidden email]>
> Subject: Re: [erlang-questions] ErlGuten
>
> Wanted to add to the issues the reasons --
>
> ** When some JPEG image is embedded into the PDF, it turns out dark in the
> generated PDF file [Happens due to CYMK color profile.]
> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> generate the PDF file. Debugging shows that the delay is on defilter(Method
> , Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
> Alpha channel presence]
>
>
>
> On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:
>
> > Thanks Lloyd for your detailed explanation on what has been done, and
> your
> > vision for the library. However we are already using ErlGuten in one of
> our
> > production systems, and the issues is mainly with the images.
> >
> > I will definitely keep an eye on the development of erlpress_core in the
> > future, as you seem enthusiastic about making it a lively library.
> >
> > The issues we have are:
> >
> > ** When some JPEG image is embedded into the PDF, it turns out dark in
> the
> > generated PDF file
> > ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> > generate the PDF file. Debugging shows that the delay is on defilter(
> > Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
> >
> > Did you come acrsoss this?
> >
> > Best,
> > Theepan
> >
> >
> >
> >
> >
> > On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
> >
> >> Hi Theepan,
> >>
> >> 1. If you look at ErlGuten source, you'll see that function
> documentation
> >> is fairly minimal and many parameters have single character names with
> >> little to no documentation. This makes maintenance and revision very
> >> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
> >>
> >> I also found the high-level page make-up functions provided by Hugh and
> >> Carl limited with respect to professional page make-up and, to me at
> least,
> >> a bit confusing.
> >>
> >> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
> >> lineage.
> >>
> >> erlpress_core is based on Joe's font-handling, justification, and XML
> >> parsing code with few if any changes. But it provides map structures to
> >> represent nearly all of the PDF objects represented in eg_pdf_op.erl.
> These
> >> map structures incorporate many default parameters so generating PDF
> >> documents is syntactically simple and consistent without sacrificing
> >> expressive flexibility. You can easily customize display by
> instantiating
> >> map parameters with your own values.
> >>
> >> You can see most of the PDF objects currently supported by
> erlpress_core,
> >> including boxed text, justification options, and various line and text
> >> objects, demonstrated in ep_show_n_tell.pdf and the source in
> >> ep_show_n_tell.erl.
> >>
> >> If you look at the map definitions of the various PDF objects, you'll
> see
> >> how to customize display.
> >>
> >> At some point if would be good to re-write the base Erlguten modules
> with
> >> more explicit function and parameter documentation, but I'm not up to
> that
> >> at this point. But, anyone looking for a challenge is free to jump in.
> >>
> >> I'm currently working on tables and text flow across pages (think
> reports
> >> and book chapters). Hope to deliver these features plus much code
> polishing
> >> in the next release coming "real soon now."
> >>
> >> High on my wish/to-do list are:
> >>
> >> -- Easy-to_use page-grid design functions
> >> -- Imposition (printing multiple page impressions on a single sheet of
> >> paper stock)
> >> -- Articles and beads (think text jumping across  columns and pages)
> >> -- Easy-to-use and expressive page make-up functions
> >> -- Example templates for various print formats
> >> -- Markdown input
> >> -- Support of TTF and OTF fonts
> >>
> >> Joe Armstrong expressed the following goal when he first announced
> >> ErlGuten:
> >>
> >> "Better than TeX."
> >>
> >> That's a tall order, yet to be realized. My hope is that erlpress will
> >> move the ball further down the field.
> >>
> >> 2. I haven't done anything with image formats beyond what you'll find in
> >> eg_pdf_image.erl. I'd welcome work in that direction.
> >>
> >> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
> >> toward sufficient functionality and stability to support a web
> application
> >> that we have currently under development.
> >>
> >> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
> >> for maps.
> >>
> >> I see the erlpress_core library as a valuable library for embedding PDF
> >> generation into Erlang applications and as the basis for many exciting
> >> Erlang-based print production tools.
> >>
> >> So, Treepan, I appreciate your interest and would welcome your
> >> involvement in testing and feature development.
> >>
> >> I would jump for joy if some Erlang guru were to step forward take on
> the
> >> TTF/OTF support issue. I've done some research and have a few ideas on
> how
> >> expanded font support might be accomplished, but have too little time
> over
> >> the next several months to dig into it.
> >>
> >> Incidentally, in my previous post my iPad decided it was smarter than me
> >> and erroneously corrected my GitHUb address.it should be
> >> writersglen/erlPress_core.
> >>
> >> My intention is to bag the camel case in my next release with luck in a
> >> week or two so it should look like writersglen/erlpress_core.
> >>
> >> All the best,
> >>
> >> Lloyd
> >>
> >>
> >> -----Original Message-----
> >> From: "Theepan" <[hidden email]>
> >> Sent: Monday, September 24, 2018 3:59pm
> >> To: [hidden email]
> >> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
> >> Armstrong" <[hidden email]>
> >> Subject: Re: [erlang-questions] ErlGuten
> >>
> >> Hi Lloyd,
> >>
> >> Thank you for your response. I have some quick clarifications --
> >>
> >> * What are the major improvements made on the source ErlGuten? Did you
> >> improve support to different image formats? Any critical bugs fixed?
> >> * Is erlPress_core used in commercial applications, specifically of high
> >> throughput types?
> >> * What is the minimum erlang/OTP version required?
> >>
> >> Best,
> >> Theepan
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <
> [hidden email]>
> >> wrote:
> >>
> >> > Hi Thepan,
> >> >
> >> > I’ve undertaken a major revision of ErlGuten called erlPress_core—
> >> > announced it on Erlang questions several weeks ago.  It’s available
> from
> >> > GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> >> > accessible than the ErlGutens.
> >> >
> >> > I’ve since been polishing up the code and adding a few new features.
> >> After
> >> > the launch I learned that camel case is not conventional usage when it
> >> > comes to the names of Erlang applications and libraries. So I plan to
> >> > release the updated version as erlpress_core. With smooth sailing I
> >> hope to
> >> > release sometime this week or next.
> >> >
> >> > All the best,
> >> >
> >> > Lloyd
> >> >
> >> > Sent from my iPad
> >> >
> >> > On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
> >> >
> >> >
> >> > Hi Team,
> >> >
> >> > I see many forks of ErlGuten. Which one is the latest, most stable and
> >> > widely used?
> >> >
> >> > https://github.com/richcarl/erlguten
> >> > https://github.com/CarlWright/NGerlguten
> >> > https://github.com/hwatkins/erlguten/commits/master
> >> >
> >> > Best,
> >> > Theepan
> >> >
> >> >
> >> > _______________________________________________
> >> > erlang-questions mailing list
> >> > [hidden email]
> >> > http://erlang.org/mailman/listinfo/erlang-questions
> >> >
> >> >
> >>
> >>
> >>
>
>
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Sean Hinde-4
In reply to this post by Theepan
Yeah. Erlang is not normally seen as the ultimate language for that kind of image processing. For my application I need the alpha channel, so that's me.

If it becomes a bigger perf problem I would imagine some integration with libpng is in order.

I don't see why the alpha channel should require a named process, but I've not got very far with my usage. Will check - thanks for the heads up

And the code isn't actually that complex - it's mostly just that PDF itself is fairly complex

Sean

On 25 Sep 2018, at 20:45, Theepan <[hidden email]> wrote:

Hi Sean,

I used GraphicsMagic to remove the alpha channel before passing onto ErlGuten. It ensures that the code not taking that inefficient path. It works very well.

I hope ErlGuten needs to be improved for image embedding support and performance using port. Also when the alpha channel is removed, eg_pdg gen_server can be made to work for parallel PDF generation by removing the local name registration.

Best,
Theepan



On Tue, Sep 25, 2018 at 7:50 PM Sean Hinde <[hidden email]> wrote:
I hit the same issue. I guess you are using one of the versions with lots of lists:nth.

Following find my patch on the version I was using.

You can find my branch at:


No time right now to make nice pull requests - I will eventually

===============================================

diff --git a/src/eg_pdf_image.erl b/src/eg_pdf_image.erl
index 1a97e0b..817f1b8 100644
--- a/src/eg_pdf_image.erl
+++ b/src/eg_pdf_image.erl
@@ -431,11 +431,11 @@ extractScanLines(Width,Decompressed) ->

 extractLine(ScanLines,Width,<< >>) ->
   AlmostDone = lists:reverse(ScanLines),
-  [ {0, string:chars(0,Width-1)} | AlmostDone];
+  [ {0, list_to_binary(string:chars(0,Width-1))} | AlmostDone];
 extractLine(ScanLines,Width,Image) ->
   LineSize = Width - 1,
   << Method:8, Line:LineSize/binary-unit:8, Rest/binary>> = Image,
-  extractLine([{Method,  binary_to_list(Line) } | ScanLines ], Width, Rest).
+  extractLine([{Method,  Line} | ScanLines ], Width, Rest).

 %% @doc Remove the filter on all the bytes in the scan lines.

@@ -448,19 +448,26 @@ processLine([{_Method, _Line1}], _Iter, _Offset, Results)->
    A = lists:flatten( lists:reverse(Results) ),
    list_to_binary( A );
 processLine([{_, Line1},{Method, Line2} | Remainder], Iter, Offset, Results) ->
-  {ok, Unfiltered} = defilter(Method, Line1, Line2,Offset,length(Line1),Iter),
+  {ok, Unfiltered} = defilter(Method, Line1, Line2,Offset,size(Line1),Iter),
   processLine([{Method, Unfiltered } | Remainder], Iter, Offset, [Unfiltered | Results] ).

 %% @doc Taking two lines of stream defilter the 2nd with the previously defiltered 1st line.

 defilter(Method, Line1, Line2, Offset, Width, Iter) when Iter =< Width ->
   NewVal = case Iter =< Offset of
-    true ->  filter(lists:nth(Iter,Line2), 0, lists:nth(Iter,Line1), 0, Method);
-    false ->  filter(lists:nth(Iter,Line2), lists:nth(Iter-Offset,Line2), lists:nth(Iter,Line1), lists:nth(Iter-Offset,Line1), Method)
+    true ->  filter(binary:at(Line2, Iter - 1), 0,
+                    binary:at(Line1, Iter - 1), 0, Method);
+    false ->  filter(binary:at(Line2, Iter - 1),
+                     binary:at(Line2, Iter - Offset - 1),
+                     binary:at(Line1, Iter - 1),
+                     binary:at(Line1, Iter - Offset - 1), Method)
     end,
     L2 = case Iter == Width of
-      true -> lists:flatten([lists:sublist(Line2,Iter - 1),NewVal]);
-      false -> lists:flatten([lists:sublist(Line2,Iter - 1),NewVal,lists:nthtail(Iter, Line2)])
+      true -> Start = binary:part(Line2, 0, Iter - 1),
+              <<Start/binary, NewVal>>;
+      false -> Start = binary:part(Line2, 0, Iter - 1),
+               End = binary:part(Line2, Iter, size(Line2) - Iter),
+               <<Start/binary, NewVal, End/binary>>
     end,
     defilter(Method, Line1, L2 ,Offset, Width, Iter+1);
 defilter(_Method, _Line1, Line2, _Offset, _Width, _Iter) ->
@@ -513,8 +520,7 @@ inflate_stream(Data) ->
   Decompressed = zlib:inflate(Z, Data),
   ok = zlib:inflateEnd(Z),
   zlib:close(Z),
-  F = fun(A, B) -> <<A/binary, B/binary>> end,
-  MergedBinaries = lists:foldr(F, <<>>, Decompressed),
+  MergedBinaries = iolist_to_binary(Decompressed),
   {ok,MergedBinaries}.

 %% @doc Compress a bit stream using the zlib/deflate algorithm

===============================================

On 25 Sep 2018, at 01:15, Theepan <[hidden email]> wrote:

Thanks Lloyd for your detailed explanation on what has been done, and your vision for the library. However we are already using ErlGuten in one of our production systems, and the issues is mainly with the images.

I will definitely keep an eye on the development of erlpress_core in the future, as you seem enthusiastic about making it a lively library.

The issues we have are: 

** When some JPEG image is embedded into the PDF, it turns out dark in the generated PDF file
** When some PNG file is embedded, it takes too long (unto 5 minutes) to generate the PDF file. Debugging shows that the delay is on defilter(Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.

Did you come acrsoss this?

Best,
Theepan





On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
Hi Theepan,

1. If you look at ErlGuten source, you'll see that function documentation is fairly minimal and many parameters have single character names with little to no documentation. This makes maintenance and revision very difficult. I consider the core ErlGuten modules diamonds-in-the-rough.

I also found the high-level page make-up functions provided by Hugh and Carl limited with respect to professional page make-up and, to me at least, a bit confusing.

But erlpress_core owes a deep debt and much gratitude to the ErlGuten lineage.

erlpress_core is based on Joe's font-handling, justification, and XML parsing code with few if any changes. But it provides map structures to represent nearly all of the PDF objects represented in eg_pdf_op.erl. These map structures incorporate many default parameters so generating PDF documents is syntactically simple and consistent without sacrificing expressive flexibility. You can easily customize display by instantiating map parameters with your own values.

You can see most of the PDF objects currently supported by erlpress_core, including boxed text, justification options, and various line and text objects, demonstrated in ep_show_n_tell.pdf and the source in ep_show_n_tell.erl.

If you look at the map definitions of the various PDF objects, you'll see how to customize display.

At some point if would be good to re-write the base Erlguten modules with more explicit function and parameter documentation, but I'm not up to that at this point. But, anyone looking for a challenge is free to jump in.

I'm currently working on tables and text flow across pages (think reports and book chapters). Hope to deliver these features plus much code polishing in the next release coming "real soon now."

High on my wish/to-do list are:

-- Easy-to_use page-grid design functions
-- Imposition (printing multiple page impressions on a single sheet of paper stock)
-- Articles and beads (think text jumping across  columns and pages)
-- Easy-to-use and expressive page make-up functions
-- Example templates for various print formats
-- Markdown input
-- Support of TTF and OTF fonts

Joe Armstrong expressed the following goal when he first announced ErlGuten:

"Better than TeX."

That's a tall order, yet to be realized. My hope is that erlpress will move the ball further down the field.

2. I haven't done anything with image formats beyond what you'll find in eg_pdf_image.erl. I'd welcome work in that direction.

3. erlpress_core is still at Version 0.01. It's just out. I'm working toward sufficient functionality and stability to support a web application that we have currently under development.

4. I developed erlpress_core on Erlang/OTP 19. It does require support for maps.

I see the erlpress_core library as a valuable library for embedding PDF generation into Erlang applications and as the basis for many exciting Erlang-based print production tools.

So, Treepan, I appreciate your interest and would welcome your involvement in testing and feature development.

I would jump for joy if some Erlang guru were to step forward take on the TTF/OTF support issue. I've done some research and have a few ideas on how expanded font support might be accomplished, but have too little time over the next several months to dig into it.

Incidentally, in my previous post my iPad decided it was smarter than me and erroneously corrected my GitHUb address.it should be writersglen/erlPress_core.

My intention is to bag the camel case in my next release with luck in a week or two so it should look like writersglen/erlpress_core.

All the best,

Lloyd


-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 3:59pm
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Hi Lloyd,

Thank you for your response. I have some quick clarifications --

* What are the major improvements made on the source ErlGuten? Did you
improve support to different image formats? Any critical bugs fixed?
* Is erlPress_core used in commercial applications, specifically of high
throughput types?
* What is the minimum erlang/OTP version required?

Best,
Theepan






On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
wrote:

> Hi Thepan,
>
> I’ve undertaken a major revision of ErlGuten called erlPress_core—
> announced it on Erlang questions several weeks ago.  It’s available from
> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> accessible than the ErlGutens.
>
> I’ve since been polishing up the code and adding a few new features. After
> the launch I learned that camel case is not conventional usage when it
> comes to the names of Erlang applications and libraries. So I plan to
> release the updated version as erlpress_core. With smooth sailing I hope to
> release sometime this week or next.
>
> All the best,
>
> Lloyd
>
> Sent from my iPad
>
> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>
>
> Hi Team,
>
> I see many forks of ErlGuten. Which one is the latest, most stable and
> widely used?
>
> https://github.com/richcarl/erlguten
> https://github.com/CarlWright/NGerlguten
> https://github.com/hwatkins/erlguten/commits/master
>
> Best,
> Theepan
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Dmytro Lytovchenko
In reply to this post by Lloyd R. Prentice-2
I am doing a prettifying pass now:
  • Adding function specs
  • Converting text specs to normal -spec specs
  • Adding named types where they make sense
  • Replacing tabs with spaces
  • Running Dialyzer on it, and fixing types so it makes sense
  • ... that sort of thing.
Can't promise when it will be finished, a day or two, or 3 weeks. You'll have a pull request when its done. Will be a MASSIVE changeset but no actual logic affected.


On Tue, 25 Sep 2018 at 18:51, <[hidden email]> wrote:
Hi Theepan,

Other than display in my demo PDF, I haven't worked much with images.

The issues you've run across seem serious. Getting at the root of the problems will likely involve a deep dive into both the PDF reference manuals and core ErlGuten source code.

As I noted in my earlier email, ErlGuten source code is very challenging. It would benefit significantly from re-write, possibly refactoring in some cases and definitely systematic documentation of functions and parameters.

I'm not confident that my skills are up to this. My take is that it would require some amount of community effort to put ErlGuten/erlpress_core on a solid, maintainable base. I would dearly love to see this happen.

Is there a CS major or intern out there with time to take on the challenges?

Joe showed us the way and I, for one, am deeply grateful. Given that PDF is a significant standard in the print media world, Erlang deserves to have a world-class library and suite of tools to generate PDF documents and decode them back into Erlang structures.

This will take community effort.

All the best,

Lloyd





-----Original Message-----
From: "Theepan" <[hidden email]>
Sent: Monday, September 24, 2018 7:27pm
To: "Lloyd Prentice" <[hidden email]>
Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

Wanted to add to the issues the reasons --

** When some JPEG image is embedded into the PDF, it turns out dark in the
generated PDF file [Happens due to CYMK color profile.]
** When some PNG file is embedded, it takes too long (unto 5 minutes) to
generate the PDF file. Debugging shows that the delay is on defilter(Method
, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
Alpha channel presence]



On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:

> Thanks Lloyd for your detailed explanation on what has been done, and your
> vision for the library. However we are already using ErlGuten in one of our
> production systems, and the issues is mainly with the images.
>
> I will definitely keep an eye on the development of erlpress_core in the
> future, as you seem enthusiastic about making it a lively library.
>
> The issues we have are:
>
> ** When some JPEG image is embedded into the PDF, it turns out dark in the
> generated PDF file
> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> generate the PDF file. Debugging shows that the delay is on defilter(
> Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
>
> Did you come acrsoss this?
>
> Best,
> Theepan
>
>
>
>
>
> On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
>
>> Hi Theepan,
>>
>> 1. If you look at ErlGuten source, you'll see that function documentation
>> is fairly minimal and many parameters have single character names with
>> little to no documentation. This makes maintenance and revision very
>> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
>>
>> I also found the high-level page make-up functions provided by Hugh and
>> Carl limited with respect to professional page make-up and, to me at least,
>> a bit confusing.
>>
>> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
>> lineage.
>>
>> erlpress_core is based on Joe's font-handling, justification, and XML
>> parsing code with few if any changes. But it provides map structures to
>> represent nearly all of the PDF objects represented in eg_pdf_op.erl. These
>> map structures incorporate many default parameters so generating PDF
>> documents is syntactically simple and consistent without sacrificing
>> expressive flexibility. You can easily customize display by instantiating
>> map parameters with your own values.
>>
>> You can see most of the PDF objects currently supported by erlpress_core,
>> including boxed text, justification options, and various line and text
>> objects, demonstrated in ep_show_n_tell.pdf and the source in
>> ep_show_n_tell.erl.
>>
>> If you look at the map definitions of the various PDF objects, you'll see
>> how to customize display.
>>
>> At some point if would be good to re-write the base Erlguten modules with
>> more explicit function and parameter documentation, but I'm not up to that
>> at this point. But, anyone looking for a challenge is free to jump in.
>>
>> I'm currently working on tables and text flow across pages (think reports
>> and book chapters). Hope to deliver these features plus much code polishing
>> in the next release coming "real soon now."
>>
>> High on my wish/to-do list are:
>>
>> -- Easy-to_use page-grid design functions
>> -- Imposition (printing multiple page impressions on a single sheet of
>> paper stock)
>> -- Articles and beads (think text jumping across  columns and pages)
>> -- Easy-to-use and expressive page make-up functions
>> -- Example templates for various print formats
>> -- Markdown input
>> -- Support of TTF and OTF fonts
>>
>> Joe Armstrong expressed the following goal when he first announced
>> ErlGuten:
>>
>> "Better than TeX."
>>
>> That's a tall order, yet to be realized. My hope is that erlpress will
>> move the ball further down the field.
>>
>> 2. I haven't done anything with image formats beyond what you'll find in
>> eg_pdf_image.erl. I'd welcome work in that direction.
>>
>> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
>> toward sufficient functionality and stability to support a web application
>> that we have currently under development.
>>
>> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
>> for maps.
>>
>> I see the erlpress_core library as a valuable library for embedding PDF
>> generation into Erlang applications and as the basis for many exciting
>> Erlang-based print production tools.
>>
>> So, Treepan, I appreciate your interest and would welcome your
>> involvement in testing and feature development.
>>
>> I would jump for joy if some Erlang guru were to step forward take on the
>> TTF/OTF support issue. I've done some research and have a few ideas on how
>> expanded font support might be accomplished, but have too little time over
>> the next several months to dig into it.
>>
>> Incidentally, in my previous post my iPad decided it was smarter than me
>> and erroneously corrected my GitHUb address.it should be
>> writersglen/erlPress_core.
>>
>> My intention is to bag the camel case in my next release with luck in a
>> week or two so it should look like writersglen/erlpress_core.
>>
>> All the best,
>>
>> Lloyd
>>
>>
>> -----Original Message-----
>> From: "Theepan" <[hidden email]>
>> Sent: Monday, September 24, 2018 3:59pm
>> To: [hidden email]
>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>> Armstrong" <[hidden email]>
>> Subject: Re: [erlang-questions] ErlGuten
>>
>> Hi Lloyd,
>>
>> Thank you for your response. I have some quick clarifications --
>>
>> * What are the major improvements made on the source ErlGuten? Did you
>> improve support to different image formats? Any critical bugs fixed?
>> * Is erlPress_core used in commercial applications, specifically of high
>> throughput types?
>> * What is the minimum erlang/OTP version required?
>>
>> Best,
>> Theepan
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <[hidden email]>
>> wrote:
>>
>> > Hi Thepan,
>> >
>> > I’ve undertaken a major revision of ErlGuten called erlPress_core—
>> > announced it on Erlang questions several weeks ago.  It’s available from
>> > GitHub as Writersglen/erlPress_core. I think you’ll find it much more
>> > accessible than the ErlGutens.
>> >
>> > I’ve since been polishing up the code and adding a few new features.
>> After
>> > the launch I learned that camel case is not conventional usage when it
>> > comes to the names of Erlang applications and libraries. So I plan to
>> > release the updated version as erlpress_core. With smooth sailing I
>> hope to
>> > release sometime this week or next.
>> >
>> > All the best,
>> >
>> > Lloyd
>> >
>> > Sent from my iPad
>> >
>> > On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>> >
>> >
>> > Hi Team,
>> >
>> > I see many forks of ErlGuten. Which one is the latest, most stable and
>> > widely used?
>> >
>> > https://github.com/richcarl/erlguten
>> > https://github.com/CarlWright/NGerlguten
>> > https://github.com/hwatkins/erlguten/commits/master
>> >
>> > Best,
>> > Theepan
>> >
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > [hidden email]
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> >
>>
>>
>>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten

Lloyd R. Prentice-2
Yeah Dmytro!

All the best,

Lloyd

-----Original Message-----
From: "Dmytro Lytovchenko" <[hidden email]>
Sent: Tuesday, September 25, 2018 4:06pm
To: [hidden email]
Cc: "Erlang/OTP discussions" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten

I am doing a prettifying pass now:

   - Adding function specs
   - Converting text specs to normal -spec specs
   - Adding named types where they make sense
   - Replacing tabs with spaces
   - Running Dialyzer on it, and fixing types so it makes sense
   - ... that sort of thing.

Can't promise when it will be finished, a day or two, or 3 weeks. You'll
have a pull request when its done. Will be a MASSIVE changeset but no
actual logic affected.


On Tue, 25 Sep 2018 at 18:51, <[hidden email]> wrote:

> Hi Theepan,
>
> Other than display in my demo PDF, I haven't worked much with images.
>
> The issues you've run across seem serious. Getting at the root of the
> problems will likely involve a deep dive into both the PDF reference
> manuals and core ErlGuten source code.
>
> As I noted in my earlier email, ErlGuten source code is very challenging.
> It would benefit significantly from re-write, possibly refactoring in some
> cases and definitely systematic documentation of functions and parameters.
>
> I'm not confident that my skills are up to this. My take is that it would
> require some amount of community effort to put ErlGuten/erlpress_core on a
> solid, maintainable base. I would dearly love to see this happen.
>
> Is there a CS major or intern out there with time to take on the
> challenges?
>
> Joe showed us the way and I, for one, am deeply grateful. Given that PDF
> is a significant standard in the print media world, Erlang deserves to have
> a world-class library and suite of tools to generate PDF documents and
> decode them back into Erlang structures.
>
> This will take community effort.
>
> All the best,
>
> Lloyd
>
>
>
>
>
> -----Original Message-----
> From: "Theepan" <[hidden email]>
> Sent: Monday, September 24, 2018 7:27pm
> To: "Lloyd Prentice" <[hidden email]>
> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
> Armstrong" <[hidden email]>
> Subject: Re: [erlang-questions] ErlGuten
>
> Wanted to add to the issues the reasons --
>
> ** When some JPEG image is embedded into the PDF, it turns out dark in the
> generated PDF file [Happens due to CYMK color profile.]
> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> generate the PDF file. Debugging shows that the delay is on defilter(Method
> , Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
> Alpha channel presence]
>
>
>
> On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:
>
> > Thanks Lloyd for your detailed explanation on what has been done, and
> your
> > vision for the library. However we are already using ErlGuten in one of
> our
> > production systems, and the issues is mainly with the images.
> >
> > I will definitely keep an eye on the development of erlpress_core in the
> > future, as you seem enthusiastic about making it a lively library.
> >
> > The issues we have are:
> >
> > ** When some JPEG image is embedded into the PDF, it turns out dark in
> the
> > generated PDF file
> > ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
> > generate the PDF file. Debugging shows that the delay is on defilter(
> > Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
> >
> > Did you come acrsoss this?
> >
> > Best,
> > Theepan
> >
> >
> >
> >
> >
> > On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
> >
> >> Hi Theepan,
> >>
> >> 1. If you look at ErlGuten source, you'll see that function
> documentation
> >> is fairly minimal and many parameters have single character names with
> >> little to no documentation. This makes maintenance and revision very
> >> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
> >>
> >> I also found the high-level page make-up functions provided by Hugh and
> >> Carl limited with respect to professional page make-up and, to me at
> least,
> >> a bit confusing.
> >>
> >> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
> >> lineage.
> >>
> >> erlpress_core is based on Joe's font-handling, justification, and XML
> >> parsing code with few if any changes. But it provides map structures to
> >> represent nearly all of the PDF objects represented in eg_pdf_op.erl.
> These
> >> map structures incorporate many default parameters so generating PDF
> >> documents is syntactically simple and consistent without sacrificing
> >> expressive flexibility. You can easily customize display by
> instantiating
> >> map parameters with your own values.
> >>
> >> You can see most of the PDF objects currently supported by
> erlpress_core,
> >> including boxed text, justification options, and various line and text
> >> objects, demonstrated in ep_show_n_tell.pdf and the source in
> >> ep_show_n_tell.erl.
> >>
> >> If you look at the map definitions of the various PDF objects, you'll
> see
> >> how to customize display.
> >>
> >> At some point if would be good to re-write the base Erlguten modules
> with
> >> more explicit function and parameter documentation, but I'm not up to
> that
> >> at this point. But, anyone looking for a challenge is free to jump in.
> >>
> >> I'm currently working on tables and text flow across pages (think
> reports
> >> and book chapters). Hope to deliver these features plus much code
> polishing
> >> in the next release coming "real soon now."
> >>
> >> High on my wish/to-do list are:
> >>
> >> -- Easy-to_use page-grid design functions
> >> -- Imposition (printing multiple page impressions on a single sheet of
> >> paper stock)
> >> -- Articles and beads (think text jumping across  columns and pages)
> >> -- Easy-to-use and expressive page make-up functions
> >> -- Example templates for various print formats
> >> -- Markdown input
> >> -- Support of TTF and OTF fonts
> >>
> >> Joe Armstrong expressed the following goal when he first announced
> >> ErlGuten:
> >>
> >> "Better than TeX."
> >>
> >> That's a tall order, yet to be realized. My hope is that erlpress will
> >> move the ball further down the field.
> >>
> >> 2. I haven't done anything with image formats beyond what you'll find in
> >> eg_pdf_image.erl. I'd welcome work in that direction.
> >>
> >> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
> >> toward sufficient functionality and stability to support a web
> application
> >> that we have currently under development.
> >>
> >> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
> >> for maps.
> >>
> >> I see the erlpress_core library as a valuable library for embedding PDF
> >> generation into Erlang applications and as the basis for many exciting
> >> Erlang-based print production tools.
> >>
> >> So, Treepan, I appreciate your interest and would welcome your
> >> involvement in testing and feature development.
> >>
> >> I would jump for joy if some Erlang guru were to step forward take on
> the
> >> TTF/OTF support issue. I've done some research and have a few ideas on
> how
> >> expanded font support might be accomplished, but have too little time
> over
> >> the next several months to dig into it.
> >>
> >> Incidentally, in my previous post my iPad decided it was smarter than me
> >> and erroneously corrected my GitHUb address.it should be
> >> writersglen/erlPress_core.
> >>
> >> My intention is to bag the camel case in my next release with luck in a
> >> week or two so it should look like writersglen/erlpress_core.
> >>
> >> All the best,
> >>
> >> Lloyd
> >>
> >>
> >> -----Original Message-----
> >> From: "Theepan" <[hidden email]>
> >> Sent: Monday, September 24, 2018 3:59pm
> >> To: [hidden email]
> >> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
> >> Armstrong" <[hidden email]>
> >> Subject: Re: [erlang-questions] ErlGuten
> >>
> >> Hi Lloyd,
> >>
> >> Thank you for your response. I have some quick clarifications --
> >>
> >> * What are the major improvements made on the source ErlGuten? Did you
> >> improve support to different image formats? Any critical bugs fixed?
> >> * Is erlPress_core used in commercial applications, specifically of high
> >> throughput types?
> >> * What is the minimum erlang/OTP version required?
> >>
> >> Best,
> >> Theepan
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <
> [hidden email]>
> >> wrote:
> >>
> >> > Hi Thepan,
> >> >
> >> > I’ve undertaken a major revision of ErlGuten called erlPress_core—
> >> > announced it on Erlang questions several weeks ago.  It’s available
> from
> >> > GitHub as Writersglen/erlPress_core. I think you’ll find it much more
> >> > accessible than the ErlGutens.
> >> >
> >> > I’ve since been polishing up the code and adding a few new features.
> >> After
> >> > the launch I learned that camel case is not conventional usage when it
> >> > comes to the names of Erlang applications and libraries. So I plan to
> >> > release the updated version as erlpress_core. With smooth sailing I
> >> hope to
> >> > release sometime this week or next.
> >> >
> >> > All the best,
> >> >
> >> > Lloyd
> >> >
> >> > Sent from my iPad
> >> >
> >> > On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
> >> >
> >> >
> >> > Hi Team,
> >> >
> >> > I see many forks of ErlGuten. Which one is the latest, most stable and
> >> > widely used?
> >> >
> >> > https://github.com/richcarl/erlguten
> >> > https://github.com/CarlWright/NGerlguten
> >> > https://github.com/hwatkins/erlguten/commits/master
> >> >
> >> > Best,
> >> > Theepan
> >> >
> >> >
> >> > _______________________________________________
> >> > erlang-questions mailing list
> >> > [hidden email]
> >> > http://erlang.org/mailman/listinfo/erlang-questions
> >> >
> >> >
> >>
> >>
> >>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten + a short survey

Loïc Hoguin-3
In reply to this post by Lloyd R. Prentice-2
As you know I will at some point[0] want to make Asciidoc produce PDF
files so I may end up wanting to use it. However from what I've seen so
far I'm not sure it would be very helpful.

My main concern is that from the Asciidoc I get an AST that has little
pagination information attached. I would therefore need to go from that
Asciidoc-AST to a sort of PDF-AST which comes with pagination
information and can then be used to generate the PDF using the PDF
drawing primitives. I have not seen code to automatically paginate in
erlguten/erlpress_core but maybe I missed it. Then there's all the
concerns about table of contents, figure listings and whatnot.

Writing the PDF itself could be done by erlguten/erlpress_core, but it
could also just be building an iolist on the fly like I do for man
pages[1]. This would be similar to what projects like PHP's fpdf library
are doing. Writing the PDF is not a big concern either way since
Asciidoc has limited capabilities compared to PDF.

In other words, as far as I can tell so far, erlguten seems to solve a
different problem than the one I am mainly concerned with. But I've only
done a cursory examination of erlguten/erlpress_core so it's possible
that I missed something.

[0] This or next Christmas. Probably.
[1] https://git.ninenines.eu/asciideck.git/tree/src/asciideck_to_manpage.erl

On 09/25/2018 09:42 PM, [hidden email] wrote:

> Hi folks,
>
> As Theepan says,  "PDF generation library is crucial to most of the commercial
> applications."
>
> If you are using ErlGuten, please help inform my work on erlpress_core:
>
> 1. What are you using it for?
> 2. What features do you wish it has but doesn't?
>
> Many thanks,
>
> Lloyd
>
> -----Original Message-----
> From: "Theepan" <[hidden email]>
> Sent: Tuesday, September 25, 2018 2:55pm
> To: "Lloyd Prentice" <[hidden email]>
> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
> Subject: Re: [erlang-questions] ErlGuten
>
> Hi Lloyd,
>
> You are right. PDF generation library is crucial to most of the commercial
> applications. The code base is not very complicated, but then again we need
> somebody who has time and willingness to take on the work. Please find what
> have written to Sean on what improvements can be crucial short term.
>
> Wish work arounds and short fixes we could achieve the required scemantics,
> performance and throughput out of ErlGuten.
>
> Best,
> Theepan
>
>
>
> On Tue, Sep 25, 2018 at 10:21 PM <[hidden email]> wrote:
>
>> Hi Theepan,
>>
>> Other than display in my demo PDF, I haven't worked much with images.
>>
>> The issues you've run across seem serious. Getting at the root of the
>> problems will likely involve a deep dive into both the PDF reference
>> manuals and core ErlGuten source code.
>>
>> As I noted in my earlier email, ErlGuten source code is very challenging.
>> It would benefit significantly from re-write, possibly refactoring in some
>> cases and definitely systematic documentation of functions and parameters.
>>
>> I'm not confident that my skills are up to this. My take is that it would
>> require some amount of community effort to put ErlGuten/erlpress_core on a
>> solid, maintainable base. I would dearly love to see this happen.
>>
>> Is there a CS major or intern out there with time to take on the
>> challenges?
>>
>> Joe showed us the way and I, for one, am deeply grateful. Given that PDF
>> is a significant standard in the print media world, Erlang deserves to have
>> a world-class library and suite of tools to generate PDF documents and
>> decode them back into Erlang structures.
>>
>> This will take community effort.
>>
>> All the best,
>>
>> Lloyd
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: "Theepan" <[hidden email]>
>> Sent: Monday, September 24, 2018 7:27pm
>> To: "Lloyd Prentice" <[hidden email]>
>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>> Armstrong" <[hidden email]>
>> Subject: Re: [erlang-questions] ErlGuten
>>
>> Wanted to add to the issues the reasons --
>>
>> ** When some JPEG image is embedded into the PDF, it turns out dark in the
>> generated PDF file [Happens due to CYMK color profile.]
>> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
>> generate the PDF file. Debugging shows that the delay is on defilter(Method
>> , Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
>> Alpha channel presence]
>>
>>
>>
>> On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:
>>
>>> Thanks Lloyd for your detailed explanation on what has been done, and
>> your
>>> vision for the library. However we are already using ErlGuten in one of
>> our
>>> production systems, and the issues is mainly with the images.
>>>
>>> I will definitely keep an eye on the development of erlpress_core in the
>>> future, as you seem enthusiastic about making it a lively library.
>>>
>>> The issues we have are:
>>>
>>> ** When some JPEG image is embedded into the PDF, it turns out dark in
>> the
>>> generated PDF file
>>> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
>>> generate the PDF file. Debugging shows that the delay is on defilter(
>>> Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
>>>
>>> Did you come acrsoss this?
>>>
>>> Best,
>>> Theepan
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
>>>
>>>> Hi Theepan,
>>>>
>>>> 1. If you look at ErlGuten source, you'll see that function
>> documentation
>>>> is fairly minimal and many parameters have single character names with
>>>> little to no documentation. This makes maintenance and revision very
>>>> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
>>>>
>>>> I also found the high-level page make-up functions provided by Hugh and
>>>> Carl limited with respect to professional page make-up and, to me at
>> least,
>>>> a bit confusing.
>>>>
>>>> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
>>>> lineage.
>>>>
>>>> erlpress_core is based on Joe's font-handling, justification, and XML
>>>> parsing code with few if any changes. But it provides map structures to
>>>> represent nearly all of the PDF objects represented in eg_pdf_op.erl.
>> These
>>>> map structures incorporate many default parameters so generating PDF
>>>> documents is syntactically simple and consistent without sacrificing
>>>> expressive flexibility. You can easily customize display by
>> instantiating
>>>> map parameters with your own values.
>>>>
>>>> You can see most of the PDF objects currently supported by
>> erlpress_core,
>>>> including boxed text, justification options, and various line and text
>>>> objects, demonstrated in ep_show_n_tell.pdf and the source in
>>>> ep_show_n_tell.erl.
>>>>
>>>> If you look at the map definitions of the various PDF objects, you'll
>> see
>>>> how to customize display.
>>>>
>>>> At some point if would be good to re-write the base Erlguten modules
>> with
>>>> more explicit function and parameter documentation, but I'm not up to
>> that
>>>> at this point. But, anyone looking for a challenge is free to jump in.
>>>>
>>>> I'm currently working on tables and text flow across pages (think
>> reports
>>>> and book chapters). Hope to deliver these features plus much code
>> polishing
>>>> in the next release coming "real soon now."
>>>>
>>>> High on my wish/to-do list are:
>>>>
>>>> -- Easy-to_use page-grid design functions
>>>> -- Imposition (printing multiple page impressions on a single sheet of
>>>> paper stock)
>>>> -- Articles and beads (think text jumping across  columns and pages)
>>>> -- Easy-to-use and expressive page make-up functions
>>>> -- Example templates for various print formats
>>>> -- Markdown input
>>>> -- Support of TTF and OTF fonts
>>>>
>>>> Joe Armstrong expressed the following goal when he first announced
>>>> ErlGuten:
>>>>
>>>> "Better than TeX."
>>>>
>>>> That's a tall order, yet to be realized. My hope is that erlpress will
>>>> move the ball further down the field.
>>>>
>>>> 2. I haven't done anything with image formats beyond what you'll find in
>>>> eg_pdf_image.erl. I'd welcome work in that direction.
>>>>
>>>> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
>>>> toward sufficient functionality and stability to support a web
>> application
>>>> that we have currently under development.
>>>>
>>>> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
>>>> for maps.
>>>>
>>>> I see the erlpress_core library as a valuable library for embedding PDF
>>>> generation into Erlang applications and as the basis for many exciting
>>>> Erlang-based print production tools.
>>>>
>>>> So, Treepan, I appreciate your interest and would welcome your
>>>> involvement in testing and feature development.
>>>>
>>>> I would jump for joy if some Erlang guru were to step forward take on
>> the
>>>> TTF/OTF support issue. I've done some research and have a few ideas on
>> how
>>>> expanded font support might be accomplished, but have too little time
>> over
>>>> the next several months to dig into it.
>>>>
>>>> Incidentally, in my previous post my iPad decided it was smarter than me
>>>> and erroneously corrected my GitHUb address.it should be
>>>> writersglen/erlPress_core.
>>>>
>>>> My intention is to bag the camel case in my next release with luck in a
>>>> week or two so it should look like writersglen/erlpress_core.
>>>>
>>>> All the best,
>>>>
>>>> Lloyd
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: "Theepan" <[hidden email]>
>>>> Sent: Monday, September 24, 2018 3:59pm
>>>> To: [hidden email]
>>>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>>>> Armstrong" <[hidden email]>
>>>> Subject: Re: [erlang-questions] ErlGuten
>>>>
>>>> Hi Lloyd,
>>>>
>>>> Thank you for your response. I have some quick clarifications --
>>>>
>>>> * What are the major improvements made on the source ErlGuten? Did you
>>>> improve support to different image formats? Any critical bugs fixed?
>>>> * Is erlPress_core used in commercial applications, specifically of high
>>>> throughput types?
>>>> * What is the minimum erlang/OTP version required?
>>>>
>>>> Best,
>>>> Theepan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <
>> [hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Thepan,
>>>>>
>>>>> I’ve undertaken a major revision of ErlGuten called erlPress_core—
>>>>> announced it on Erlang questions several weeks ago.  It’s available
>> from
>>>>> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
>>>>> accessible than the ErlGutens.
>>>>>
>>>>> I’ve since been polishing up the code and adding a few new features.
>>>> After
>>>>> the launch I learned that camel case is not conventional usage when it
>>>>> comes to the names of Erlang applications and libraries. So I plan to
>>>>> release the updated version as erlpress_core. With smooth sailing I
>>>> hope to
>>>>> release sometime this week or next.
>>>>>
>>>>> All the best,
>>>>>
>>>>> Lloyd
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Hi Team,
>>>>>
>>>>> I see many forks of ErlGuten. Which one is the latest, most stable and
>>>>> widely used?
>>>>>
>>>>> https://github.com/richcarl/erlguten
>>>>> https://github.com/CarlWright/NGerlguten
>>>>> https://github.com/hwatkins/erlguten/commits/master
>>>>>
>>>>> Best,
>>>>> Theepan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> erlang-questions mailing list
>>>>> [hidden email]
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten + a short survey

Sean Hinde-4

>
> My main concern is that from the Asciidoc I get an AST that has little pagination information attached. I would therefore need to go from that Asciidoc-AST to a sort of PDF-AST which comes with pagination information and can then be used to generate the PDF using the PDF drawing primitives. I have not seen code to automatically paginate in erlguten/erlpress_core but maybe I missed it. Then there's all the concerns about table of contents, figure listings and whatnot.

The table generation code in eg_table.erl does auto pagination and IIRC it was not much more than keeping track of used vertical and pushing a new page when there wasn't enough left. The rich text mechanism lets you know how many lines in each paragraph
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ErlGuten + a short survey

Lloyd R. Prentice-2
In reply to this post by Loïc Hoguin-3
Hi Loïc,

If you print out ep_show_n_tell.pdf you'll see page numbers at the bottom of each page alternating bottom flush left and flush right depending upon verso or recto page.

Pagination is specified as follows:

ep_pagination:first_page(PDF, Job),  % ****** Page1

...which prints:

Page 1

ep_pagination:next_page(PDF, Job),    % ****** Page 2

...which prints:

Page 2

...etc.

If you want a page with no pagination, then simply don't include these calls in your PDF source.

Here's the code:

first_page(PDF, Job) ->
   eg_pdf:set_pagesize(PDF,a4),
   eg_pdf:set_author(PDF,"LRP"),
   eg_pdf:set_title(PDF, "Test Elements"),
   eg_pdf:set_subject(PDF,"erlPrest work-in-progress"),
   eg_pdf:set_keywords(PDF,"Erlang, PDF, erlPress"),
   eg_pdf:new_page(PDF),
   eg_pdf:set_page(PDF,1),
   pageno(PDF, Job),
   ok.

next_page(PDF, Job) ->
    CurrentPage = eg_pdf:get_page_no(PDF),
    NextPage = CurrentPage + 1,
    eg_pdf:new_page(PDF),
    eg_pdf:set_page(PDF, NextPage),
    pageno(PDF, Job)
    ok.

You can also devise your own pagination styles using this function:

pageno(PDF, Job)->
    {Font, Size} = maps:get(page_no_font, Job),
    eg_pdf:begin_text(PDF),
    eg_pdf:set_font(PDF,Font, Size),
    A = eg_pdf:get_page_no(PDF),
    Str = "Page " ++ eg_pdf_op:n2s(A),
    Width = eg_pdf:get_string_width(PDF,"Times-Roman", 11, Str),
    case A rem 2 of
        0 ->
            eg_pdf:set_text_pos(PDF, 100, 50);
        1 ->
            eg_pdf:set_text_pos(PDF, 510 - Width, 50)
    end,
    eg_pdf:text(PDF, "Page " ++ eg_pdf_op:n2s(A)),
    eg_pdf:end_text(PDF),
    ok.

As to "table of contents, figure listings and whatnot," erlpress_core is just that, a core library upon which much can be built. And it is in its infancy. I do intend, when I can get to it, to support TOCs, figure listings, etc.-- my vision/fantasy is to create a versatile book production tool. And, while I'm at it, maybe even a magazine production tool. Who knows?

But, you are right. There is much work to be done. It could be done much faster through community involvement and collaboration. But I understand that you have your own fish to fry.

I am, however, enormously grateful for the outstanding work you have done with Cowboy and your dedication to documentation excellence.

All the best,

Lloyd

-----Original Message-----
From: "Loïc Hoguin" <[hidden email]>
Sent: Wednesday, September 26, 2018 3:04am
To: [hidden email]
Cc: "Erlang Questions Mailing List" <[hidden email]>
Subject: Re: [erlang-questions] ErlGuten + a short survey

As you know I will at some point[0] want to make Asciidoc produce PDF
files so I may end up wanting to use it. However from what I've seen so
far I'm not sure it would be very helpful.

My main concern is that from the Asciidoc I get an AST that has little
pagination information attached. I would therefore need to go from that
Asciidoc-AST to a sort of PDF-AST which comes with pagination
information and can then be used to generate the PDF using the PDF
drawing primitives. I have not seen code to automatically paginate in
erlguten/erlpress_core but maybe I missed it. Then there's all the
concerns about table of contents, figure listings and whatnot.

Writing the PDF itself could be done by erlguten/erlpress_core, but it
could also just be building an iolist on the fly like I do for man
pages[1]. This would be similar to what projects like PHP's fpdf library
are doing. Writing the PDF is not a big concern either way since
Asciidoc has limited capabilities compared to PDF.

In other words, as far as I can tell so far, erlguten seems to solve a
different problem than the one I am mainly concerned with. But I've only
done a cursory examination of erlguten/erlpress_core so it's possible
that I missed something.

[0] This or next Christmas. Probably.
[1] https://git.ninenines.eu/asciideck.git/tree/src/asciideck_to_manpage.erl

On 09/25/2018 09:42 PM, [hidden email] wrote:

> Hi folks,
>
> As Theepan says,  "PDF generation library is crucial to most of the commercial
> applications."
>
> If you are using ErlGuten, please help inform my work on erlpress_core:
>
> 1. What are you using it for?
> 2. What features do you wish it has but doesn't?
>
> Many thanks,
>
> Lloyd
>
> -----Original Message-----
> From: "Theepan" <[hidden email]>
> Sent: Tuesday, September 25, 2018 2:55pm
> To: "Lloyd Prentice" <[hidden email]>
> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe Armstrong" <[hidden email]>
> Subject: Re: [erlang-questions] ErlGuten
>
> Hi Lloyd,
>
> You are right. PDF generation library is crucial to most of the commercial
> applications. The code base is not very complicated, but then again we need
> somebody who has time and willingness to take on the work. Please find what
> have written to Sean on what improvements can be crucial short term.
>
> Wish work arounds and short fixes we could achieve the required scemantics,
> performance and throughput out of ErlGuten.
>
> Best,
> Theepan
>
>
>
> On Tue, Sep 25, 2018 at 10:21 PM <[hidden email]> wrote:
>
>> Hi Theepan,
>>
>> Other than display in my demo PDF, I haven't worked much with images.
>>
>> The issues you've run across seem serious. Getting at the root of the
>> problems will likely involve a deep dive into both the PDF reference
>> manuals and core ErlGuten source code.
>>
>> As I noted in my earlier email, ErlGuten source code is very challenging.
>> It would benefit significantly from re-write, possibly refactoring in some
>> cases and definitely systematic documentation of functions and parameters.
>>
>> I'm not confident that my skills are up to this. My take is that it would
>> require some amount of community effort to put ErlGuten/erlpress_core on a
>> solid, maintainable base. I would dearly love to see this happen.
>>
>> Is there a CS major or intern out there with time to take on the
>> challenges?
>>
>> Joe showed us the way and I, for one, am deeply grateful. Given that PDF
>> is a significant standard in the print media world, Erlang deserves to have
>> a world-class library and suite of tools to generate PDF documents and
>> decode them back into Erlang structures.
>>
>> This will take community effort.
>>
>> All the best,
>>
>> Lloyd
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: "Theepan" <[hidden email]>
>> Sent: Monday, September 24, 2018 7:27pm
>> To: "Lloyd Prentice" <[hidden email]>
>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>> Armstrong" <[hidden email]>
>> Subject: Re: [erlang-questions] ErlGuten
>>
>> Wanted to add to the issues the reasons --
>>
>> ** When some JPEG image is embedded into the PDF, it turns out dark in the
>> generated PDF file [Happens due to CYMK color profile.]
>> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
>> generate the PDF file. Debugging shows that the delay is on defilter(Method
>> , Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.[Happens due to
>> Alpha channel presence]
>>
>>
>>
>> On Tue, Sep 25, 2018 at 4:45 AM Theepan <[hidden email]> wrote:
>>
>>> Thanks Lloyd for your detailed explanation on what has been done, and
>> your
>>> vision for the library. However we are already using ErlGuten in one of
>> our
>>> production systems, and the issues is mainly with the images.
>>>
>>> I will definitely keep an eye on the development of erlpress_core in the
>>> future, as you seem enthusiastic about making it a lively library.
>>>
>>> The issues we have are:
>>>
>>> ** When some JPEG image is embedded into the PDF, it turns out dark in
>> the
>>> generated PDF file
>>> ** When some PNG file is embedded, it takes too long (unto 5 minutes) to
>>> generate the PDF file. Debugging shows that the delay is on defilter(
>>> Method, Line1, Line2, Offset, Width, Iter) of eg_pdf_image module.
>>>
>>> Did you come acrsoss this?
>>>
>>> Best,
>>> Theepan
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 25, 2018 at 2:56 AM <[hidden email]> wrote:
>>>
>>>> Hi Theepan,
>>>>
>>>> 1. If you look at ErlGuten source, you'll see that function
>> documentation
>>>> is fairly minimal and many parameters have single character names with
>>>> little to no documentation. This makes maintenance and revision very
>>>> difficult. I consider the core ErlGuten modules diamonds-in-the-rough.
>>>>
>>>> I also found the high-level page make-up functions provided by Hugh and
>>>> Carl limited with respect to professional page make-up and, to me at
>> least,
>>>> a bit confusing.
>>>>
>>>> But erlpress_core owes a deep debt and much gratitude to the ErlGuten
>>>> lineage.
>>>>
>>>> erlpress_core is based on Joe's font-handling, justification, and XML
>>>> parsing code with few if any changes. But it provides map structures to
>>>> represent nearly all of the PDF objects represented in eg_pdf_op.erl.
>> These
>>>> map structures incorporate many default parameters so generating PDF
>>>> documents is syntactically simple and consistent without sacrificing
>>>> expressive flexibility. You can easily customize display by
>> instantiating
>>>> map parameters with your own values.
>>>>
>>>> You can see most of the PDF objects currently supported by
>> erlpress_core,
>>>> including boxed text, justification options, and various line and text
>>>> objects, demonstrated in ep_show_n_tell.pdf and the source in
>>>> ep_show_n_tell.erl.
>>>>
>>>> If you look at the map definitions of the various PDF objects, you'll
>> see
>>>> how to customize display.
>>>>
>>>> At some point if would be good to re-write the base Erlguten modules
>> with
>>>> more explicit function and parameter documentation, but I'm not up to
>> that
>>>> at this point. But, anyone looking for a challenge is free to jump in.
>>>>
>>>> I'm currently working on tables and text flow across pages (think
>> reports
>>>> and book chapters). Hope to deliver these features plus much code
>> polishing
>>>> in the next release coming "real soon now."
>>>>
>>>> High on my wish/to-do list are:
>>>>
>>>> -- Easy-to_use page-grid design functions
>>>> -- Imposition (printing multiple page impressions on a single sheet of
>>>> paper stock)
>>>> -- Articles and beads (think text jumping across  columns and pages)
>>>> -- Easy-to-use and expressive page make-up functions
>>>> -- Example templates for various print formats
>>>> -- Markdown input
>>>> -- Support of TTF and OTF fonts
>>>>
>>>> Joe Armstrong expressed the following goal when he first announced
>>>> ErlGuten:
>>>>
>>>> "Better than TeX."
>>>>
>>>> That's a tall order, yet to be realized. My hope is that erlpress will
>>>> move the ball further down the field.
>>>>
>>>> 2. I haven't done anything with image formats beyond what you'll find in
>>>> eg_pdf_image.erl. I'd welcome work in that direction.
>>>>
>>>> 3. erlpress_core is still at Version 0.01. It's just out. I'm working
>>>> toward sufficient functionality and stability to support a web
>> application
>>>> that we have currently under development.
>>>>
>>>> 4. I developed erlpress_core on Erlang/OTP 19. It does require support
>>>> for maps.
>>>>
>>>> I see the erlpress_core library as a valuable library for embedding PDF
>>>> generation into Erlang applications and as the basis for many exciting
>>>> Erlang-based print production tools.
>>>>
>>>> So, Treepan, I appreciate your interest and would welcome your
>>>> involvement in testing and feature development.
>>>>
>>>> I would jump for joy if some Erlang guru were to step forward take on
>> the
>>>> TTF/OTF support issue. I've done some research and have a few ideas on
>> how
>>>> expanded font support might be accomplished, but have too little time
>> over
>>>> the next several months to dig into it.
>>>>
>>>> Incidentally, in my previous post my iPad decided it was smarter than me
>>>> and erroneously corrected my GitHUb address.it should be
>>>> writersglen/erlPress_core.
>>>>
>>>> My intention is to bag the camel case in my next release with luck in a
>>>> week or two so it should look like writersglen/erlpress_core.
>>>>
>>>> All the best,
>>>>
>>>> Lloyd
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: "Theepan" <[hidden email]>
>>>> Sent: Monday, September 24, 2018 3:59pm
>>>> To: [hidden email]
>>>> Cc: "Erlang Questions Mailing List" <[hidden email]>, "Joe
>>>> Armstrong" <[hidden email]>
>>>> Subject: Re: [erlang-questions] ErlGuten
>>>>
>>>> Hi Lloyd,
>>>>
>>>> Thank you for your response. I have some quick clarifications --
>>>>
>>>> * What are the major improvements made on the source ErlGuten? Did you
>>>> improve support to different image formats? Any critical bugs fixed?
>>>> * Is erlPress_core used in commercial applications, specifically of high
>>>> throughput types?
>>>> * What is the minimum erlang/OTP version required?
>>>>
>>>> Best,
>>>> Theepan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 24, 2018 at 6:36 AM Lloyd R. Prentice <
>> [hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Thepan,
>>>>>
>>>>> I’ve undertaken a major revision of ErlGuten called erlPress_core—
>>>>> announced it on Erlang questions several weeks ago.  It’s available
>> from
>>>>> GitHub as Writersglen/erlPress_core. I think you’ll find it much more
>>>>> accessible than the ErlGutens.
>>>>>
>>>>> I’ve since been polishing up the code and adding a few new features.
>>>> After
>>>>> the launch I learned that camel case is not conventional usage when it
>>>>> comes to the names of Erlang applications and libraries. So I plan to
>>>>> release the updated version as erlpress_core. With smooth sailing I
>>>> hope to
>>>>> release sometime this week or next.
>>>>>
>>>>> All the best,
>>>>>
>>>>> Lloyd
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Sep 23, 2018, at 8:30 PM, Theepan <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Hi Team,
>>>>>
>>>>> I see many forks of ErlGuten. Which one is the latest, most stable and
>>>>> widely used?
>>>>>
>>>>> https://github.com/richcarl/erlguten
>>>>> https://github.com/CarlWright/NGerlguten
>>>>> https://github.com/hwatkins/erlguten/commits/master
>>>>>
>>>>> Best,
>>>>> Theepan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> erlang-questions mailing list
>>>>> [hidden email]
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions