search

sethyuan / logseq-plugin-doc

Show page in a more document like look and provide quick exporting.
MIT License
90 stars 4 forks source link

Make TOC Links from logseq-plugin-tocgen working in HTML export #22

Closed acsr closed 2 years ago

acsr commented 2 years ago

I tried also if my suggestion from the initial issue post to make the Table of Contents from your other plugin https://github.com/sethyuan/logseq-plugin-tocgen work to jump to anchors in the same HTML. see Note on TOCs: https://github.com/sethyuan/logseq-plugin-doc/issues/20

It would be good to know if fixing the TOC challenge would be be fine here in the DOC plugin or better solved in the https://github.com/sethyuan/logseq-plugin-tocgen.

When solved there the Target Anchors could be opened in the same HTML only if anchors are included in the html. Otherwise the links can just point to the block itself in Logseq and opens in the app as well.

Feel free to ask if something is unclear.

sethyuan commented 2 years ago

I think I need to modify the source code of both projects to achieve this. I'll come back to you when I have progress.

sethyuan commented 2 years ago

I published new versions of logseq-plugin-tocgen and logseq-plugin-doc, can you give it a try? They should be handled well now.

acsr commented 2 years ago

@sethyuan Great work, thank you, what a fast response. First of all: works mostly as expected and needed. I added more feedback below.

Suggestion: Please make the hint to the lazy load challenge more prominent in the docs (Put sticky to front!) I removed a remark on this here after finally finding it already there. (in a former unedited version of this comment)

Howto preserve Links and TOC jumps in PDF (can become part of the docs)

Links including TOC Anchor jumps are preserved when printing the PDF from Safari, but not from Chrome. Firefox et al not testet.

Virtual Page break in PDF Export after Title and Properties and before a long unfolded TOC

Occurs in both Chrome and Safari.

Reason: The div with the TOC seems to be preserved a one block on the PDF page because it did not fit the firstpage because of the header. A short unfolded TOC remains on page 1. TOCS exceeding one page or scaling the page not tested yet. Needs more testing ...

Remaining challenges.

  1. Unfolding the TOC before export helps to get the full TOC into the HTML unfolded (Good for PDF!).

    • Nice to have: Export the full TOC but fold like visible state and allow to unfold in HTML (not needed for PDF)

  2. Extending the markup of the Anchor Headlines. Having the Link to the Headline (Anchor Link with Chain Icon) visible on Hover after the Headline (convenient if the page is integrated elsewhere for reference. Experienced users can fetch the info from source or the TOC)

    • A Back to TOC Link on the headline itself in the content or at the end of the line (Up Arrow icon)
    • A Back to top Link at the end.
sethyuan commented 2 years ago

A few observations from my end:

acsr commented 2 years ago
  • "Links in PDF" when I printed from Chrome were preserved, I'm on macOS and I opened the printed PDF using the Preview app. For links that open Logseq, I needed to right click on the link in PDF.

Links in PDF from Chrome were only preserved for me for "fully visible https://... links" , Logseq links not at all from Chrome. Same in Acrobat Reader.

I used Chrome Version 103.0.5060.114 (Official Build) (x86_64) on MacOS Mojave. PDF generated either by:

But this maybe an issue of the old OS/Version, since the PDF printing is handled from the OS Driver. We have everything here from HighSierra, Mojave, Catalina, BigSur, Monterey. But Logeq not on all machines.

Maybe you can share the exact setup/procedure for Chrome you used.

I need to come back on the other stuff later.

sethyuan commented 2 years ago

I released a new version with the following modifications:

I didn't implement a back to top button at the end of the page because I don't think it's standard for a document. An alternative for it might be to just use a back to TOC arrow.

acsr commented 2 years ago
  1. Back to top works great and opening the TOC at the slot is great when the TOC is long.
  2. Page break before long TOCs is now gone, but may introduce new issues by missing newlines in the HTML at other locations in content when just newlines are present (e.g. properties blocks, source code blocks etc.) .
    • You can discover these flaws already in the HTML.
    • I have no fast setup to compare that with the old version that much, but I saved the old test exports and they have no issue.
    • See attached Screenshots with properties example
    • Maybe you can fix this with a more restrictive CSS selector for your new markup.
    • To do future testing it could help to create a test.md file containing all the common different markup cases (including your own plugins special markup, e.g. your logseq-wrap works great!).
      • For a different project, I suggested to add a sample markup snippet to the package that can be concatenated to a global test document. I know that this cannot cover all permutations of the result. Alternatively it can be published on github only, but I think it does not bloat the package that much. This is more relevant for Logseq itself but helpful for your plugin in particular.
image
sethyuan commented 2 years ago

Found the issue, it's due to how I implemented the back arrow, I just fixed it. You can try the new version.

acsr commented 2 years ago

I can confirm, that the Line Feed rendering issue with he properties etc. is gone.

Remaining issues, maybe new Ticket or related. Chose as needed and create a new one.

  1. TOC links level 6+ in HTML pointing to blocks in loseq not anchors But I discovered now that I missed to find an issue with the TOC links pointing to the Anchors are not working in HTML (and PDF) below level 5 of the TOC either expanded by hand in Logseq or setting the default in the plugin prefs, (Option to set it explicit in the content seems missing).
    • The Links in HTML below Level 5 still point to the Logseq Block ID
    • This was already present in former versions, but not recognized by me
  2. Properties Fieldnames in HTML are (now?) linking to a fictive Logseq page with the name of the property, showing nothing else when property name is not already given to a page or tag.
    • This was already present in former versions, but not recognized by me, because the Links were not visible as Links. I discovered this by accident while the CSS was not fully loaded and the properties appeared as links for a glimpse.
    • Could have been recognized when looking into the HTML source, but was blind from the initial working random samples I tried.
sethyuan commented 2 years ago

I just made a test, TOC links with deep levels do behave well.

image

Could the link problem you mentioned somehow related to the lazy loading behavior of Logseq?

Regarding the 2nd issue, it seems to be a Logseq's bug, you can observe it without using the plugin. Doc View Exporter works by replicating Logseq's view, so this issue should be gone when it's fixed by Logseq.

sethyuan commented 2 years ago

Regarding the 2nd issue, it seems to be a Logseq's bug, you can observe it without using the plugin. Doc View Exporter works by replicating Logseq's view, so this issue should be gone when it's fixed by Logseq.

I found a Logseq setting that controls this behavior:

;; Enable all your properties to have corresponding pages
 :property-pages/enabled? true
acsr commented 2 years ago

Youre so cool and responsive. Need to try that out in detail later next week. I think if I can 4 eyes confirm these findings by you, it should be reflected in the docs and we can close this ticket then. cu