Maroto Document Processor

[johnfercher]

RFC: https://docs.google.com/document/d/1DfmeED0Nxt11bwvpZGVK51IE20sP6kCjoqQVrOSVqZE

Hello fellows, we are about to create a document processor to generate PDFs by interpreting serialized data as: yml, json or html. I know that there are projects that transform HTML to PDF, but I feel that we can do something simpler and better.

props:
    imageHeader:
        align: center

row 10:
    col 4:
        img "https://raw.githubusercontent.com/johnfercher/maroto/master/docs/assets/images/logosmall.png" imageHeader
    col 8:
        qrcode "qrcode content"
        text "text content"

This is just an idea, I would like to evolve this with you.

[khorevaa]

Привет,
Интересный проект по генерации документов PDF через описание документа по специальной json схеме
Основная возможность что привлекает - отсутствие необходимости работы с координатами элементов - использование различных
layouts

---

Eng
Hi,
An interesting project for generating PDF documents through a document description using a special json scheme
The main feature that attracts is the absence of the need to work with the coordinates of the elements - the use of different layouts

https://github.com/apple-x-co/go-pdf

[icanc0]

Id love to have templating in this, we can write custom serializers and let maroto fill in the data.

[johnfercher]

Nice to know @icanc0, may you provide an example of what would be good to have in this feature?

[icanc0]

That's a great question, I don't want the templating to be too complex, but I think the following features would be nice (from most important to least important).

• Follow necessary subsets of templating languages
  • JSON-T, maybe even Jinja or Templ
• Generate types for consumers
• Modularity, a good interface for future file formats that can be used as templates

[nemo0]

This is a great idea. Generating PDFs from JSON and YML files can be very helpful.

[andboson]

Hello guys
It is such a great project!
Will watch it
Just one word about PDF generation from HTML:
we can use frontend - devs to create HTML documents.

[awnyshaheen]

it would be amazing!
in the template example you provided, would it be possible to automatically detect size if size not provided? maybe size should not be included in the label?

[Fernando-hub527]

it would be amazing! in the template example you provided, would it be possible to automatically detect size if size not provided? maybe size should not be included in the label?

Hmm. We could do something like this:

 row: {
           height: 10
            col: {...}
}

and if the height is not provided use the Maroto autorow. What do you think?

[johnfercher]

We started this implementation: https://docs.google.com/document/d/1DfmeED0Nxt11bwvpZGVK51IE20sP6kCjoqQVrOSVqZE

@Fernando-hub527

Any ideas?

[Fernando-hub527]

I was thinking we could create a project to organize all the tasks related to the processor implementation. It’d give us a good overview of our progress and make it easier for everyone to jump in. What do you think?

[Fernando-hub527]

Hello! We’ve started implementing the processor and would like to know your opinion about how we are generating the components.

As outlined in the RFC, we won’t be converting the document directly into a structure. Instead, we’ll create an interface map and develop components from there.

I believe this method has some advantages, as we mentioned in the RFC, but it does add a bit of complexity to the solution. I’d like to hear your feedback on this approach and if you have any suggestions for achieving the benefits we discussed.

[johnfercher]

To me this is a good approach.

[zjom]

Hi! I really like this idea.

For my use case, a short lived command line tool would be most useful, similar to pandoc.

I would love to help out in bringing this to life.

Perhaps the repository interface could look something like this.

type Repository interface {
	Get(name string) (map[string]any, error)
	Register(name string, t map[string]any) (Repository, error)
	Delete(name string) (Repository, error)
	Dump() map[string]map[string]any   // useful to get all the templates out and save to a folder or smth
}

I'm using map[string]any as a temporary placeholder for the interface map

A simple in memory repo implementation would look like

type repository struct {
	templates map[string]map[string]any
}

func New(templates map[string]map[string]any) Repository {
	return &repository{templates}
}

func (r repository) Get(name string) (map[string]any, error) {
	if t, ok := r.templates[name]; ok {
		return t, nil
	}

	return nil, fmt.Errorf("template not found with name: %s", name)
}

func (r *repository) Register(name string, t map[string]any) (Repository, error) {
	var next = map[string]map[string]any{}
	maps.Copy(next, r.templates)
	next[name] = t
	return &repository{templates: next}, nil
}

func (r *repository) Delete(name string) (Repository, error) {
	var next = map[string]map[string]any{}
	maps.Copy(next, r.templates)
	delete(next, name)
	return &repository{templates: next}, nil
}

func (r *repository) Dump() map[string]map[string]any {
	return r.templates
}

[Fernando-hub527]

Very good!
We are using this branch to develop this feature, and I believe your contribution would be greatly appreciated!

Regarding the CLI tools, the idea is for the processor and the API to run independently. This allows us to create CLI tools that generate PDFs from structured documents.

[Fernando-hub527]

Since the PDF can be generated via an external request, we need to define how the images and other documents used by the Maroto components will be loaded.

We’ve outlined some important points on this in the RFC.

@zjom I believe that once the images are loaded, they should be stored in a repository. The repository would then be passed as a parameter to the processor, which would use it to generate the PDF. This would allow the processor to access the images without needing to know how they were loaded, addressing the considerations we added in the RFC. What do you think of this approach?

[zjom]

I created a PR with some of these changes, including a simple implementation of the asset loader.

link

I'm not entirely sure how to implement the deserialiser but I'll give it a crack soon.

Let me know what you think!

[Fernando-hub527]

I really liked the implementation! I'll even refactor some things based on what you did.

I had an idea on how to upload the documents, I added a suggestion in rfc I’d like to hear what you think about it!

[zjom]

I do like the idea of a resources array but I'm a little concerned about the ergonomics of it for the user. If I understand it correctly, the template will include a source_key for the asset matching the name of the asset in resources array. This forces the user to keep track of the source_key-path for the asset and seems inconvenient and error prone. Perhaps for constant paths, we should allow for the user to specify the path directly in the template. When parsing the template, if we encounter a constant path, we could spin up a go routine to fetch it. This approach would be slightly slower than having the resources array to begin with but it creates a nicer user experience.

[zjom]

I implemented an MVP for loading resources into memory when deserialising according to the suggestion in the rfc. Let me know what you think. We may have to limit how many go routines are created to fetch the resources but for now I think it is ok.

I am still a little concerned about the ergonomics of the template but provided that the users will generate the templates programatically, it may be ok

[Fernando-hub527]

You raised a great point. I think your suggestion to add static path directly to the model improves usability. We could use the resource array only in the model computation.

I see two options:

1. We could refactor your PR to allow constant paths to be passed directly into the model. I don’t think this would have a major impact on performance, as the model isn’t constantly redefined. The resource array would then be used only during model computation.
2. Alternatively, we could stick with the approach of receiving an array with paths. Once the feature is complete, we can gather feedback from library users and refactor as needed.

what do you think ?