Love the Servive -- Want to offer my help [ ISSUES ]

[Felix-The-Ghost]

Hello augnustin,

I'm happy to see you have been engaging with people here that have submitted issues. I hope this post will be productive.

I'm inferring from these graphics on the site that your vision is the most consistent / comparable experience to the "real" doc. That is highly respectable and I want to help.

I have a live Google Doc here. (It's a guide for a mobile game I play)

For convenient navigation the document features links to the other published formats at the top.

I'd like to draw attention to several (I believe resolvable) formatting discrepancies between published formats:

1. Images have 2px margins on left and right on "real" document:
2. Images have overflow:hidden in publication :(

Google

Publication

You can see the overflow causes a display issue and the lack of the margins on images makes these images in a series "cramped"

3. Default CSS for header elements (h1-h6) have margins when in the context of the generated document they should be overwritten to 0px;

Google

Publication

4. Google Docs applies a 60% scale to superscript elements (font-size:60%;) not seen in publications

Google

Publication

In mobile viewing:

5. Bullet font-size should be set to 100% (defaults to 200% for me)
6. Left/right padding of content should be ~12% instead of set to 72pt

Mobile Publication

Some of these can be immediately resolved with just css. Others require "fixing" (removing) problematic generated css styles hard coded directly to HTML elements (maybe there's a way to have priority CSS that bypasses direct HTML styles, I'm not totally update to date in my knowledge)

What I saw was images were in a span element with a fixed width (instead of auto) and overflow:hidden (instead of visible)

Please let me know if I can assist or clarify these issues in any way. Would love to test a beta version of any fixes.

Thank you!

[augnustin]

Hello Felix,

Thanks for your positive feedback. Your issue is very well documented, congrats.

Regarding the differences you did observe between the Google version and the gdoc.pub version, I'm afraid there is not so much I can do: you have to be aware that the only info I have there is the published version of google (here) and all the differences you mention are there too.

I can override some rules, but they have to be the very general case, while here, those are highly specific and I can't see how to extract some general rules out of those. Eg. even if I try to remove the overflow: hidden; from images (which is already slightly tricky), I can't be sure that this will work out in every document. Especially because there are multiple ways to display images in a google doc, and this would require to test them all.

As a conclusion, I would say that :

1. if you want to help, you are very much welcome to fork the repo to write your own rules and try to see if you can find something general. This would imply having several test document and make sure this still works for all of them

2. If this feels like too complicated, and that those differences matter too much (do they after all?), try to play around your google doc to see if you can get something better.

Eg. I guess if you set manually the margin below the h1, it will be reflected correctly. For images, try to play with rendering mode, or in the end, you could eventually try to add margin to the images themselves.

Very hacky, I agree, but do not forget that gdoc.pub is a hack by itself. I never understood why google did not commit the little energy it required to push the "publish to the web" feature forward ...

[Felix-The-Ghost]

TL;DR: Headers and list-items (and document margin?) seem immediately fixable, other elements less simple

I guess if you set manually the margin below the h1, it will be reflected correctly.

I tried: set it specifically in Docs and it doesn't reflect in the publication. As I said the issue is no margin is set in your CSS so it uses browser defaults, which is a problem because the spacing is already done by the publication without margins so the margins are superfluous.

This is easily fixed in CSS:
h1, h2, h3, h4, h5, h6 { margin:0px; }

Consistent bullet sizes on mobile also easy with a general rule:
li::before { font-size: 100%; }

I also saw which container has the margins (that should be relative for mobile / smaller screens) I don't know for sure if that's always the name of the container but I assume it is.

.c106 {
    background-color: #ffffff;
    max-width: 468pt;
    padding: 12% 12% 12% 12%; // previously 72pt
}

Superscript elements are a little different. I guess the class names are dynamic from google?

e.g. class name might not be the same

.c18 {
	vertical-align: super;
	font-size: 60%;
}

Additionally relative font size only works if the elements are actually nested, but they are parallel :( so elements that have the superscript class and any font-size changing class can't use relative font-size (maybe you could detect superscript and manually adjust the font size 60%?) Might have to come back to this one.

As you said the elements where the HTML directly apply styles is beyond my current knowledge. Does your service interact with the HTML at all? Or just apply CSS for the background (and presumably something else I didn't notice)

I'd appreciate you investigating and possibly implementing those three immediately fixable issues.

[Felix-The-Ghost]

Forgot to say: perhaps it's feasible to allow the user to add their own CSS? Not sure if that's possible or not with your current system in place.

[Felix-The-Ghost]

@augnustin Have you implemented/tried anything yet? I can also respect your choice to silently ignore this. I just want this to be the best it deserves to be.

[augnustin]

Hello

As I told you, I won't have a look, but if you want to, feel free to fork the code and give it a try. I am definitely willing to help!

Cheers

[Felix-The-Ghost]

As I told you, I won't have a look

Even after re-reading your comment I see nothing implying you'd take no action

I can respect it though. I wish you'd reconsider but in the end it's your vision, not mine.