misthero commented 7 years ago

please do not completely remove raw HTML input for brew code.

For example it would be nice to have the option enable or disable "Advanced HTML option" somewhere at account or brew level and leaving it disabled by default, than you put an advice: if enabled no support!

I have no problem with it, css and html have no secrets so.. some of us can handle it..

well, anyway, thankyou for this great tool!! 👍

brianfeister commented 7 years ago

+1 for this! Can I suggest an alternate approach? (By the way, I love finding a modern, well-written web app that does amazing things, I was like "Ooooohhh, this was written in React? I bet we could wrap this in nwjs and make a desktop client 😉

And then I remembered this awesome editor from Gitbook: https://github.com/GitbookIO/editor-legacy

I bet we could fork Gitbook editor... in fact I'm thinking of doing just that, I'm a Publisher by night with a decent sized team of writers and a software developer by night, I could give an NWJS binary file for any operating system to my employees that already writes in my own company style guide.

Sorry, I was saying, I bet we could fork Gitbook editor and use that to give a rich-text editor that's backed by Markdown for people who want "simple mode", rather than removing access to RAW HTML in Markdown which helps folks like me. ;)

Also, while I'm here, sorry for straying off-topic, but any thoughts around doing PDF Bookmarks from the "Table of Contents" you generate? I'm a bit confused by this as it seems your Table of Contents function outputs links using the Markdown linking syntax, but with the recommendation to print via Chrome's "Print > Save as PDF" I assume it's not possible to preserve them. I'd really love to be able to preserve those... it's the ONE thing that keeps me from jumping right on board and using this for actual print-ready physical book prints. (Well that and the fact that I'm waiting to get confirmation from my printers that the XML / PDF binary data output via this Chrome Save As PDF method is satisfactory for commercial printing. Fingers are crossed.

/cc @stolksdorf

stolksdorf commented 7 years ago

@misthero I'll do a more in depth write on this when I pick v3 back up (taking a break from the project to regain some motivation on it), but simply allowing raw HTML is probably the worst decision I have made with this project.

The HTML spec is large, convoluted, and inconsistent. Consistently and reliably rendering PHB styling across OS, browsers, and PDF rendering is nigh impossible. People keep surprising me with how they bend the HTML spec.
Most people don't know how to write HTML. This leads to unexpected bugs, weird rendering, and overall just a bad feeling with this tool when it's advertised to be easy. Little things that programmers easily catch, like mixing up quote styles, forgetting a closing tag, capitalizing classes; These go unnoticed and cause unseen issues.
It creates fragmentation within the community. The whole goal of this tool was to make homebrewing easier, but raw HTML exchanged having expertise with Photoshop with having expertise with HTML/CSS. Worse yet people will just copy and paste snippets of other's homebrew HTML without understanding how it actual works and make a tangled mess of their project. I have many emails from people of this happening.
Supporting and debugging people's bad HTML is exhausting. I would estimate that 60-80% of the reported bugs are because of bad HTML. It's incredibly difficult for me to actually know what is really a bug and what is just someone forgetting to close a tag halfway through their document.
It limits my ability to add new features, because I have to test against virtually any possible web page.
I don't want to work on a glorified HTML editor. This has been done to death, it's not an interesting project.

My solution:

Removed HTML. It just renders as raw text
Removed all weird markdown combinations to get certain elements, eg. ___ then a table. All markdown elements map to their regular HTML counterparts.
Added a separate CSS override editor. Has good syntax highlighting and descriptive errors.
Modified the markdown parsing engine to add a new element type called 'blocks', which render a simple divs. eg. {{red,wide,table ... }} -> <div class='red wide table> ...

`

Not only does this fix every one of the pain points I listed, but actually makes a better experience for seasoned developers. All of your crazy styling is isolated away from your content, and you can easily copy and paste your stylesheets in between your brews. You also should still have most of the creative control of raw HTML without the annoyance of parsing or writing it.

This is mostly done, and I will be releasing a staging version of the new rendering engine to the community to test it out before I release.

Ultimately, if you still really want to write raw HTML, the PHB stylesheet I wrote is open source, so you can just use your favorite code editor and write your own PHB webpage using that.

@brianfeister I am planning on experimenting with an Electron-based desktop Homebrewery client, which uses the file system instead of my databases. This will be post v3 launch. Re: TOC links, in my experience all anchor tag links are persevered when you print to PDF.

brianfeister commented 7 years ago

@misthero Really important question, if you have a quick moment!

Thanks for the thorough response, your proposal with doing handlebars-style blocks sounds sufficient! 👍

The problem I'm running into here is actually that the 27 page PDF I'm printing out is coming out to 127Mb. I believe that this is because of the usage of base64 encoded data-uri's for the background texture which fails to recognize and properly "re-use" the image asset in the saved PDF. At this very moment, I'm tinkering with html-pdf in hopes that it might consume the generated HTML response and create a more sane resulting PDF.

Any thoughts on this? I think I'm using the project for more than it was intended but my hope is that maybe you've already encountered and thought about this problem?

stolksdorf commented 7 years ago

@brianfeister quick fix for you, download the background image, upload to imgur. Use CSS to change the background image of your pages to that URL, that should fix your problem. In v3 I've removed base64 encoded assets, another bad decision 😢

brianfeister commented 7 years ago

@stolksdorf Actually for what it's worth I'm much deeper in than that 😉 ... I've actually tried that already and it doesn't fix the issue.

I forked your project and done various tweaks to the server / API / client that suit my use case (removing auth, amongst others and making the /admin page show everything in mongo), trying to get html-pdf going now.

stolksdorf commented 7 years ago

As a heads up most, most HTML to PDF libs use a headless webkit (or at least a part of it) to generate PDFs, so you won't really see any difference using different libs. The first version of Homebrewery used to do PDF gen on server, but it sucked.

I would also verify that it is the background images causing the bloat. So try removing them and see what happens.

brianfeister commented 7 years ago

@stolksdorf confirmed two things:

1) Yes, it's the background causing it (123Mb ==> 12Mb) 2) Using an externally linked image (instead of data URI) doesn't improve the problem, as I had initially suspected. It must be Chrome's Print as PDF handling that fails to properly re-use linked assets with the same name. It must dump EVERY ONE of them as non-reusable binary data.

As an addendum 3) Ouch, really stings, that's why I was going the html-pdf route. Was really hoping to use this to generate PDFs, I believe this is the only total blocker. html-pdf of course generates a completely unstyled PDF. I've done (just local dev hacks) an const compiledCSS = require('fs').readFileSync('./build/homebrew/bundle.css', 'utf8') and injected the styles into an <style> tag in <head> but so far no dice.

brianfeister commented 7 years ago

Update @stolksdorf I wish I had a solution that could address the problem at it's root, however, I'm just under such a tight deadline and I DO think I can use the files you're outputting, I just need to run them through this tool, it took the 123Mb file down to 6.4Mb. 👍

https://smallpdf.com/compress-pdf

brianfeister commented 7 years ago

@stolksdorf by the way, ping me if you start working on the electron app, I'd like to pitch in.

DoctorDan1986 commented 7 years ago

I'd be interested in a standalone app (for both Windows and macOS) that could have full functionality when offline, and which acted as a desktop client when online. I'd love to be able to directly pull resources from my computer without uploading them to imgur or something, for example.

There's also the benefit of having hard backups of my stuff. Cloud computing is neat, but I guess I'm old school.

brianfeister commented 7 years ago

For what it's worth I'm doing exactly that with the existing codebase having just forked this repo and running it locally

DoctorDan1986 commented 7 years ago

Tried doing that, followed the directions on gitHub, doesn't work. Be easier for those of us who aren't technologically inclined to have a standalone app instead of "bash this" or "npm that" and who just want to create.

stolksdorf commented 7 years ago

@DoctorDan1986 I understand the sentiment, but really it's just moving the work onto someone else to do. It will most likely take me months of work to get a standalone app working (after I finish v3), so I wouldn't hold your breath.

calculuschild commented 3 years ago

Added to the V3 changelog finally. Closing.

naturalcrit / homebrewery

please keep html #395

please do not completely remove raw HTML input for brew code.