Export Source Dialog #163
Export Source Dialog #163
Conversation
|
Update:
|
|
Reports:
|
|
Question: When exporting to toher formats than printer or pdf the export doesn't contain any font information. While it is generally a good idea not to use hardcoded fonts in html output it might come in handy when creating snippets that should work standalone, i.e. not fit themeselves nicely in an existing design. |
|
Apart from testing I definitely need feedback on the question of the printer set up (bottom right 'cell' of the dialog). |
|
Sorry: I'm very busy, that's why I didn't yet manage to look at this! I just checked it out and will test the coming few days! |
|
If I know that now it's ok to wait. Next week I'll be away and won't have time for any serious work, but probably for some discussion. I know it's not ready to be merged, but I wasn't really able to continue without some feedback. Particularly on the open 'printer' issue, but also on the several issues I have already reported myself. Basically it works pretty good now. If you look at our LilyPond blog you'll notice I'm using it quite heavily ;-) |
|
I think the dialog could be simplified by moving settings like leading zeroes, preferred stylesheet handling to a Preferences page. We could then make a menu action File->Export Formatted Source Text... (or, shorter, Export Source...) that opens the dialog. The dialog could have a combobox chooser for the main types (Html, PDF, ODF Text, PNG image). Then buttons: Cancel, Preview, Save As..., Copy to Clipboard In the Edit menu the command Copy as colored Html can remain as-is (using the HTML stylesheet handling from the preferences page). This way the action Export with previous settings (which is somewhat unclear) can be removed. The dialog simply should remember its state. Will checkback later and I now have somewhat more time... :) |
|
I think I could merge this pull request and then re-add the old Print Source option. Then just add the dialog and re-work it so it is more comprehensible. |
Applied updates: - Insert line break before first style in css for export - export colored (styled) HTML (body only) - copy styled HTML - export CSS file - copy as (inline) styled HTML code - export (inline) styled HTML (body only) - Refactor copy source commands Improve interface: - suggest "lilypond.css" as filename - use current dir as default or - user's home dir if current file isn't saved Integrate html_document and html_selection - HTML is now always generated from a selection. When exporting the whole document the selection is simply expanded to the document HTML-export: Refactor HTML getter method - Process incoming LilyPond source line by line (instead of token by token). This Will be used for further refinements of output
- Combine consecutive elements Consecutive elements, i.e. tokens of the same class, separated by spaces (e.g. "c d e f") are now wrapped in one single <span> element. - Handle block comments correctly Block comments were rendered to HTML very tokenized so far. This wasn't good HTML style and sometimes caused Web editors to scramble the results by purging whitespace. Now block comments are rendered as class="lilypond-comment" on a line-by-line basis. While still being slightly redundant this will allow to easily copy&paste single lines from the result.
Move highlight2html.py into export module start unifying the interface to the export functions (only one function for the content and one light wrapper for the whole document. Behaviour isn't set by function arguments but by properties of the options object) Fix colorize.py th reflect the modifications Add dummy for the new dialog
- Add "external css" option exports html source code with reference to an external style sheet. Only makes sense with - document="full" - format="html" - pad first line When exporting a selection the first line is prepended by an appropriate number of " " so it starts at the original position in the line - Empty clipboard on cancel
Export options are now stored with the global QSettings object. They are persistent throughout the session, can be saved explicitely (from the "Export source" dialog) or implicitely (Checkbox in Preferences->General) The Dialog itself is a mere dummy yet. At least it shows disabling of the "Save" button, Cancel and OK work too (Cancel clears the clipboard) The export options can't be edited in this intermediate state. Default values can be set in export/__init__.py, but they will be overwritten through the Settings.
- Merge routines for printing and exporting to pdf. Printing now uses the highlight2html approach like exporting - Add export to ODT files TODO: PDF/Printer settings in dialog
- prepend a line number at the beginning of lines Configurable number of digits (will be changed later) For now I manually enter <span class="lilypond-linenumber"> element around the number, without having a corresponding style sheet. Should better be a new token class - Separate 'format' setting 'format' is now only the html-plain/richtext differenct 'filetype' is used for html, pdf or odt generation Having only 'format' caused issues when exporting to clipboard but 'format=pdf' was set - Work towards correct font for printout (will only be solved much later ...)
- Add elements. - Start testing interaction with Settings - Define settings variables (copy) in dialog The application logic in the dialog should work on a local copy of the export options. - Map options to widgets Use dictionaries to map options to widgets. Options are now correctly read from and written to Settings. - Implement slots WIP Bind all widgets to handlers Try to handle all depending updates (enabling widgets, propagating options) - Add file dialog - Add Print/PDF export options (Mainly finished) - Tooltips for most widgets
- Print and PDF-export respect document font When using Highlight2Html class for printing (instead of the former highlighter.py) the font wasn't respected anymore. Concretely the <pre> tag caused some different font setting to be used. Actually the font isn't used at all in HTML export, which is generally good. But maybe we add an option for that (which would then be auto-set for printing) The (slightly hacky?) solution is to conditionally inject an explicit <pre> CSS class when exporting to PDF or printer. - Correctly format linenumbers Linenumbers now have a separate textformat (in Highlight2Html) so the css will correctly be used with inline as well as css formatting - Improve printer setup dialog (start work) In order to use the printer dialog from the export dialog I think I have to use one QPrinter object in mainwindow and exportDialog
- Remove "Print source" action Print source has been merged into "export source" - Update File menu mnemonics This isn't related to source-export. Not all have been set, but significantly more than before
The content is now wrapped in a <pre class="lilypond"> tag. This should allow to override any styles on existing websites (our WordPress theme introduced a larger line-height, thus tearing apart the linenumbers styling). Currently this includes a hard-coded line-height of 120%, but this should be made configurable
pre.lilypond is now exported as an empty style class. This can be used to style the whole <pre> block that is output with the "lilypond" class. But setting it to a concrete style is the responsibility of the actual web design.
|
As a first step to pick up this work I collected all comments in the different places and created a list of todo tasks (Wilbert: You receive an invitation in parallel but are not bound to participate there). What I now think is appropriate is having one ComboBox for the main decision what the user actually wants to do. This will have entries like Depending on this selection all irrelevant options aren't greyed out but hidden completely. I think with this I can make the dialog much simpler. There is one thing I didn't understand from your comments, though: What do you mean by 'Drag squares'? |
|
I'm closing this now because the branch seems to have become unmergeable anyway. I'm feeling better if I have it privately. |
|
I like to add/keep the functionality but the dialog needs some work to become user friendly, and I think we should not remove the old print source action. Shall I try to merge the internal formatted source export functionality in a sane way? Then only the dialog is left over. |
|
I had already decided to restart this from scratch, creating a new branch and go through the old commits one by one, seeing what and how to reuse. It would be nice if you incorporate the internal functionality. That's probably faster and more reliable. I would then have a clean base to restart the dialog from scratch. |
|
Yes. Do you make a pull request for the core functionality or shall I pick the commits myself? |
|
It's probably easier if you inspect the commits yourself, trying to cherry-pick them one by one. |
|
Great! |
|
I was under the impression that I merged parts of this already but it seems not the case. I.e. the improvements of the HTML output (combine consecutive classes etc.) I'm sorry for that. The pull request was very large and you asked for testing, that has caused the delays (but also that I was very busy those days). If you had first done only the improved html generation (and tested) it would certainly have been included. In smaller steps (smaller commits and pull requests). |
|
I know. You actually did comment on the GUI quite long ago, and if I had had the time then I would have been able to pick up and maybe finish it ... |
|
Btw, combining consecutive token classes in HTML will be delayed a bit, because there is a wish for nested highlighting stuff, for example a LilyPond chord syntax that has a certain background color during the whole chord. So nested highlighting colors will be implemented first, then we''l continue optimizing the HTML output... :( |
This pull request isn't meant to be merged, but a request for review.
Before merging I would clean up the history to reduce the number of commits, and I still have a few things to do.
But I would really like to get some thorough testing now.
Overview of changes (see also #152, #156 and #159 ):
(a wish would be PNG export (for screenshots etc.) - maybe through the poppler library?)
And any valid combinations.
Testing is needed for:
or prevent legal ones?
What is still unfinished:
This css has no definition (because I don't know how to inject a new TextFormat in the tokenizer mechanism)
This will be solved with the solution of the previous issue
(need a CSS for the
<pre>tag)And a screenshot:
frescobaldi-export-dialog-test