Titou325

11 ms·

1.
by Titou325 3y ago
Elements that are placed in page regions are shared between pages with the exception of CSS generated content such as running headers. Shadows are attached as an XObject image with a SMask indeed :)
2.
by Titou325 3y ago
We indeed price starting at $0.005 per document, but have slightly updated the pricing following the good input we received yesterday from the community - hence the slight discrepancy in comments.
3.
by Titou325 3y ago
We support the size[1] property and the widows and orphans[2] spec for both your needs :) [1]: https://developer.mozilla.org/en-US/docs/Web/CSS/@page/size [2]: https://developer.mozilla.o
4.
by Titou325 3y ago
We actually take HTML as an input to our API converter. The React tooling is mostly to ease the barrier with most frontend codebases, as well as leverage the existing ecosystem of components. It seems that these conversion engines are massi
5.
by Titou325 3y ago
Really like your approach! We tried to keep things tied to code as much as possible rather than dealing with complex interfaces between changing inputs and outputs. Most legal and tech teams we talked to pointed to the fact that CI/CD
6.
by Titou325 3y ago
There are many reasons behind it, to name a few: files are self-contained(*) and easily portable, can guarantee some security features, the format is easily extended, and the ecosystem is very large. It seems that a better format should exi
7.
by Titou325 3y ago
You are right in the sense we do not provide a local library. We considered the option but would have brought a lot of challenges to accommodate the various runtimes and device capabilities. This may come at a later stage once we have built
8.
by Titou325 3y ago
Yes, Onedoc generates tagged PDFs as long as you add a `title` property to the API call to make the PDF UA/1 compliant.
9.
by Titou325 3y ago
We bill per document, so the number of pages wouldn't impact the pricing. A 5 pages invoice would come at 1 cent per page. However, it seems that each and every company has different needs and the pricing may or may not make sense for
10.
by Titou325 3y ago
While this may sound a bit counterintuitive (maybe?) we actually pivoted to this field based on YC input and discussions they have had with their previous companies. The multitude of FOSS solutions in this area indicates this is a real prob
11.
by Titou325 3y ago
It is similar to pspdfkit. We add an abstraction layer over the HTML and assets hosting to make it easier to use without having to think too hard about security and serving assets. We also hope to keep the focus on the PDF generation part r
12.
by Titou325 3y ago
This brings its own set of challenges. Headers and footers are strictly limited in terms of features, you cannot add footnotes, the notion of page spreads is harder to implement. Then you need to combine that with having a Chrome instance a
13.
by Titou325 3y ago
We are currently experimenting with this approach. A good thing about paged.js is that we would be able to provide hot-reload and live preview of files without actually converting to PDF. Your second point is very interesting, seems like so
14.
by Titou325 3y ago
We actually experimented with Gotenberg! Ultimately it is a layer on top of Chromium for conversion and we were dissatisfied with the results. I am curious so as to how are you handling assets and other static media / attachments: do y
15.
by Titou325 3y ago
We actually provide helpers to do that in our React library https://react.onedoclabs.com/components/shell#pagebreak CSS actually implements the break-before property to control this https://developer.mozilla
16.
by Titou325 3y ago
We actually provide helpers to do that in our React library https://react.onedoclabs.com/components/shell#pagebreak CSS actually implements the break-before property to control this https://developer.mozilla
17.
by Titou325 3y ago
Yes, we use an API layer on top of PrinceXML with additional polyfills to support modern features. This is a meh solution but it allowed us to iterate quickly and get to work with customers without building a full blown PDF engine firsthand
18.
by Titou325 3y ago
Makes total sense. There is no real requirement to use Tailwind to create the PDFs, we just have grown accustomed to Tailwind :) If you don't use the <Tailwind> tag, the browser defaults are used to generate the PDF.
19.
by Titou325 3y ago
We quite agree on this - but getting a new alternative out will require a significant critical mass before it can be of any interest. While PDF has its challenges, it remains a light portable format and its security features make it a good
20.
by Titou325 3y ago
The pricing does go down for larger volumes and is something we still have to narrow down to the exact place that makes sense to companies and is also viable. - We do not force PDF/* profiles down to the user, but it seems that for mos
21.
by Titou325 3y ago
We use a dedicated HTML to PDF engine (such as PrinceXML) rather than building on top of a browser. Main issue with browser-backed implementations is that PDFs are often of subpar quality. However, the main good thing is you can rely on the
22.
by Titou325 3y ago
There is both commonalities and differences! Both approaches rely on web technology to provide the layout and are flexible in terms of frameworks and integrations. Where things differ is that we don't actually use a browser under the h
23.
by Titou325 3y ago
It definitely is! Typesetting quality was the main reason we chose not to go down the Puppeteer/headless browser route but rather use a completely separate engine where typography is a first-class citizen. We like LaTeX, but even for a
24.
by Titou325 3y ago
This is a good point, and we are still trying to figure out how to price things fairly. Depending on the type of PDF, whether it is a simple receipt or a large multi-pages report, associated costs are very different on our side. At this tim
25.
by Titou325 3y ago
We are using a wrapper around PrinceXML until we can move into a separate rendering engine. We want to be able to offer the same layout features of such an engine, hopefully much faster. You can have a look at our (WIP) set of templates at
26.
by Titou325 3y ago
It could probably but I believe maintaining these two would probably be more work than accepting the drawbacks. Another advantage of supporting full-fledged React is that (in the near future) we can allow Javascript in the rendering engine,
27.
by Titou325 3y ago
Hey, Titouan part of the Onedoc team. You are absolutely correct and most existing tools do leverage a browser (sometimes headless) to convert HTML to PDF. However, browser's CSS print specification implementation is severely lacking a
28.
by Titou325 3y ago
Hi! We are the team behind Onedoc, an easy way to generate and manage documents for developers. We experienced the problem first hand creating hundreds of personalised marketing materials and working with various clients: PDF is broken. But
29.
Documents made easy for developers – Onedoc(onedoclabs.com)
3 points by Titou325 3y ago|1 comments