feat #1: demo code added

[sc231997]

This PR contains demo code for:

• Lists
• Tables

[arivera12]

Verified all files but not the demo file it's way long to read. Can you refresh https://sc231997.github.io/PdfMakeNet/ so I can go ahead a see it there running? I saw few changes I miss that are in the playground but not on the main docs.

[sc231997]

Verified all files but not the demo file it's way long to read. Can you refresh https://sc231997.github.io/PdfMakeNet/ so I can go ahead a see it there running? I saw few changes I miss that are in the playground but on the main docs.

The demo is updated now. These were some places where I was not sure how to achieve a few things, so I wrote it like this,

new { text = "someString", otherProperty = "value" }

I guess if we look at the @types/pdfmake, we will be able to figure out if we have missed any property in library.

[arivera12]

new { text = "item 1", counter = 10 }

For this kind of case that you mentioned, we should create a new class called like PdfMakeOrderedListItem & PdfMakeUnorderedListItem, both should inherit from PdfkMakeText and apply their own interface.

What you think?

[sc231997]

new { text = "item 1", counter = 10 }

For this kind of case that you mentioned, we should create a new class called like PdfMakeOrderedListItem & PdfMakeUnorderedListItem, both should inherit from PdfkMakeText and apply their own interface.

What you think?

Actually I thought of doing so but that won't work. We have to inherit every class. As instead of text there can be any other pdfmake element

[arivera12]

Actually I thought of doing so but that won't work. We have to inherit every class. As instead of text there can be any other pdfmake element

Any workaround using type params maybe?

[arivera12]

Any workaround using type params maybe?

Never mind, this approach won't work cause it will create a nested object and won't work.

[arivera12]

Can you enum what kind of types a PdfMakeOrderedListItem & PdfMakeUnorderedListItem could hold?

Another dirty option is doing explicit list items types, example:

PdfMakeOrderedTextListItem
PdfMakeUnorderedTextListItem

PdfMakeOrderedImageListItem
PdfMakeUnorderedImageListItem

... and so on

Then you can place list item specific properties like counter = 10 cause they will be added per every OrderedItem & UnorderedItem types.

You can create a interface like IPdfMakeOrderedListItem & IPdfMakeUnorderedListItem types which holds the base properties of a list item like counter = 10 and implement then on the specific list item types.

What you think about this one?

[sc231997]

You can create a interface like IPdfMakeOrderedListItem & IPdfMakeUnorderedListItem types which holds the base properties of a list item like counter = 10 and implement then on the specific list item types.

This looks interesting, but don't we have to implement this for almost all the classes?

[arivera12]

You can create a interface like IPdfMakeOrderedListItem & IPdfMakeUnorderedListItem types which holds the base properties of a list item like counter = 10 and implement then on the specific list item types.

This looks interesting, but don't we have to implement this for almost all the classes?

I don't think we have to implement it for every class, this is why I said if you can enum where does this apply.

As I understand we can have list item of type of:

1. Text
2. Image
3. Text and Image maybe?

What else?

[sc231997]

You can create a interface like IPdfMakeOrderedListItem & IPdfMakeUnorderedListItem types which holds the base properties of a list item like counter = 10 and implement then on the specific list item types.

This looks interesting, but don't we have to implement this for almost all the classes?

I don't think we have to implement it for every class, this is why I said if you can enum where does this apply.

As I understand we can have list item of type of:

1. Text
2. Image
3. Text and Image maybe?

What else?

Actually it can be anything from pdfmake:

export interface ContentUnorderedList extends ContentBase {
    ul: UnorderedListElement[];
    type?: UnorderedListType;
    markerColor?: string;
}

export type UnorderedListType = 'square' | 'circle' | 'none';
export type UnorderedListElement = Content & {
    listType?: UnorderedListType;
};

export type Content =
    | string
    | ArrayOfContent
    | ContentText
    | ContentColumns
    | ContentStack
    | ContentUnorderedList
    | ContentOrderedList
    | ContentTable
    | ContentAnchor
    | ContentPageReference
    | ContentTextReference
    | ContentToc
    | ContentTocItem
    | ContentImage
    | ContentSvg
    | ContentQr
    | ContentCanvas;

interfaces.d.ts.txt Please look at the file here. I have taken this from @types/pdfmake .

[arivera12]

I read it, it can be anything. I will merge in this change until I think a way around this. We would still need the UnorderedListType interface in the meantime. I am thinking about using reflection for this at the moment but need I to think a little bit more on how it will look like and how this may be implemented. pulling in, making a new issue for the list types.

[sc231997]

I read it, it can be anything. I will merge in this change until I think a way around this. We would still need the UnorderedListType interface in the meantime. I am thinking about using reflection for this at the moment but need I to think a little bit more on how it will look like and how this may be implemented. pulling in, making a new issue for the list types.

A dirty way could be having all those attributes under PdfMakeStyle. If someone uses the wrong attribute combination pdfmake will handle that error.

[arivera12]

hmm sounds good, very good, PdfMakeStyle it's almost on every PdfMake type.

Add your inputs and ideas here https://github.com/arivera12/PdfMakeNet/issues/9