Hacker News new | past | comments | ask | show | jobs | submit | kelvinzhang's comments login

Offline isn’t a priority at the moment but can be done in the future by packaging with Electron.

Typst is great but there are a few key differences:

- full CSS support, allowing for more customizability and familiar styling without a learning curve

- less tailored towards academic use-cases are more towards personal/business use-cases like resumes, invoices, reports. Also adding a template gallery in the near future.

- has a templating engine and API baked in

- can use JS packages and ecosystem (ex. icon sets, fonts, etc.)


The long term goal of this project is to make HTML/CSS the defacto way of typesetting PDF documents. I’ll definitely keep it running for as long as I can.

The web version is just the initial step, and will likely open source for people who want to self-host and to increase adoption. For pricing, will probably adopt a model similar to Overleaf where it’s free for most users and maybe charge for team collaboration or have an enterprise license.


If you do opensource it, happy to help maintain it. This product would be helpful for my (fledgling) company, but would need to be self-hosted (use case is esignatures)


Fixed! Sorry about that


I think in the long term, HTML/CSS will win out once there's better support for CSS Paged Module Level 3, and you'll be able to achieve that requirement with just

    @page :left {
        margin-left: 20mm;
        margin-right: 10mm;
    }
    
    @page :right {
        margin-left: 10mm;
        margin-right: 20mm;
    }

instead of needing to install/import different LaTeX packages. I think for most of my current use-cases level 2 has been sufficient but I can see if I can include Paged.js polyfill support by default so there's more support for customizability on that front.


@Page { size: A4; margin: 20mm 10mm 10mm 25mm; } Do my print specifics (hidden-print class etc), everyone can optimize it for his local layout, every browser supports "print to pdf", done.


Pricing info is in a modal under the user dropdown, it's currently based on a monthly credit system. If there's another pricing model you'd prefer, let me know!


My feedback is that I was ready to move on after I searched for pricing, and it appears that it's not shown anywhere unless I sign up. I'll give it a try because it looks interesting and I'm looking for something similar.


You can probably get away with Pandoc depending on your use-case, this is primarily built for:

- having a web editor interface without needing to re-run a CLI command

- people who don't want to deal with packages/dependencies on their own system

- users that just want an affordable and easy-to-use API to generate PDF documents instead of having to set up their own server <> task queue <> worker system which would usually cost more

- in the future, teams that want to collaborate together on a document


I think it should be on the <ul> tag. See https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_li...


This is a great suggestion and I feel dumb for not thinking of this earlier. Thanks!


Nice catch, I copy/pasted that from a previous project and forgot to remove - should be fixed now.

TOS is pretty general and just there for legal reasons, tl;dr feel free to use as you see fit as long as it's not for anything illegal.


We actually ran off of WeasyPrint at first but switched to Chromium due to emojis not rendering properly, poor flexbox support, no custom fonts, and other differences between the HTML you'd see in a browser vs. the generated PDF.

WeasyPrint implements its own rendering engine and might support some specific @page properties that Chromium does not but given the complexity of CSS and web browsers, you're generally better off sticking with Chromium due to its history.

Also – an added benefit is that we can use JS libraries like FontAwesome, Bootstrap, KaTeX, etc. which is where other HTML to PDF libraries fall flat.


Flexbox support has been [included][1] since 2018, although my use case was the prototypical one - a single row w/ 3 columns - so YMMV with how it handles more complex layouts.

[1]: https://github.com/Kozea/WeasyPrint/pull/579


In addition, so far I know, the @page "locations" (e.g, @top-center, etc.) are not well supported yet in all browsers which means the flexbox fallback is probably as close as we're going to get.

https://www.quackit.com/css/at-rules/css_top-center_at-rule....


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: