Scribusoid

Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Features / Re: Suggestion: a good start for footnotes Insert > Char > Footnote#
« Last post by jack_cat on September 14, 2018, 09:10:51 pm »
That last post will take me some time to digest.

Here I offer some comments:

#### The Paradigm Change of our time: Print vs HTML & Digitalization in general

Dragonfly's proposal for a pipeline from markdown language to Scribus raises the issue of the current paradigm change from paper to digital media, which every Scribus user must be aware of, I should think.

For 500 years paper publishing was lucrative. Paper sheet music sales were an income stream for musicians from 1500 on, reached a peak in the late 19th century, crashed with the advent of recording technology and have been nearly destroyed by the internet and at the very least must be marketed on the web.

By digitalization the value of a musical recording has been recently devalued a hundred-fold in the shift from CDs to MP3 download. A few years ago an independent musician could sell a self-produced CD for a 500% markup over the raw material, now we _pay_ for entry to the Spotify market where a listener download pays an infinitesimal trickle-down percentage.

A legacy book which I am studying is in the digital commons and available free, whereas the modern English translation, out of print but not out of copyright, is up for $1200 USD on Amazon.

An author who goes to the trouble of creating a print book using Scribus faces (1) being lost in the competition, (2) the likelihood that someone will scan it and post it on Scribd.com available almost free, (3) the fact that the same material could be formatted in HTML and published on the net for free, or sold digitally.

So, a person such as myself, thinking that I might sum up my life's work with a print volume fit to sit on a bookshelf alongside the classics (ha! right), must accept that this is a vanity project.

The open source model which is so apparent behind the proposed .md to Scribus workflow suggests that the end product might as well be free and open source, and published on the web, and so why go to print or even to printable format at all (i.e. Scribus) in my case? Markdown is already a pipeline to the web, it's primary designed purpose, and to create from it a secondary pipeline to Scribus also runs up against the McLuhan "the Medium is the Message" factor, which I can see in front of me as I type this in the Atom editor, which is alien to my thought process of the last 40 years - it offers, even full-screen, only a narrow window into the work in hand, and the Markdown Preview flows into the size of its tab, showing only content and not format.

Because "the Medium is the Message", I think of my print project in terms of a series of two-page spreads, offering a series of 17" by 11" workspaces which must each communicate as complete an idea as possible, ideally without a page turn in mid-thought, so as not to require a reader studying the material to flip pages back and forth between graphical example and explanation, being open on a music stand in front of a person whose hands are busy playing an instrument. This is different from a novel, which can be poured into Scribus as into a container, and also different from the new model of the foot-pedal-controlled scrolling PDF reader; my more traditional concept is dependent on graphical layout. At one time I contemplated doing it as a series of Illustrator files (now it would be Inkscape as I have migrated). I believe that this is also a factor for the Scribus User who recently posted about a projected animal encyclopedia.

For such a use, the proposed pipeline will need to include a quick and painless zoomable preview-as-print function, otherwise the user will be essentially working in the dark. I see that Atom can do this fairly effectively for Lilypond already, and that therefore this capacity is not out of the question. Even in Scribus, however, I must frequently export to PDF to get a clearer view, and even that is not sufficient, because the only real test, allowing a truly critical overview, is a draft print on paper, because on-screen content does not reveal many errors and my eyes play tricks, seeing what I think I have written or drawn and gliding over many errors. Even this file did not reveal several errors until I exported it to HTML and opened it in the browser.

Anyway, as I sit here contemplating, and experimenting with, the components of the proposed Atom > Markdown > Lilypond > HTML > Scribus workflow, there are two issues that arise, one practical and one more philosophical:

1. Practically, the difficulty of creating content in one medium (Atom etc) and then pouring it into a container which is likely to prove to be a procrustean bed for that content (Scribus as a container designed for the reception and formatting of lineal content such as a novel, to put the worst face on it). That is, the pipeline appears to require a certain fluidity and homogeneity of the content in order to flow; insufficiently-fluid content is likely to be sliced, diced and homogenized.

2. Philosophically, the questioning of the entire model of "print" and the use of Scribus, vs. surrendering to the tenor of the time and publishing either in HTML, or e-reader viewable PDF, thereby relinquishing the idea of selling paper books at all.

I offer no conclusions. I am going to spend some reasonable amount of time experimenting with my re-designed work flow, and consider it worth the time; as I said, Lilypond alone is a fairly long-term project. Atom is a very interesting tool, I will also require some time with it to really evaluate it.
thanks
jack_cat
52
Features / Re: Suggestion: a good start for footnotes Insert > Char > Footnote#
« Last post by dragonfly on September 14, 2018, 12:29:25 pm »
I will try to draw a close to this thread which could go on for some time since the dimension of music notation has been added. However, there are some loose ends to tie up before returning to my mainline interest - to explore hooking up Scribus to an external toolchain.

Quote
Lilypond's tag line at the end of the file is annoying and clearly undesirable, but I think that there must be a switch to turn it off instead of having to crop every file.

I have read somewhere that this can be removed by registering as a user with LilyPond.

I would delete this footer actually seen at the bottom of the SVG file.  I now see that there is no need to crop it in Inkscape other than removing white space in the produced page. But even that cropping can be done at SVG file level.

You can also tweak SVG content and see the changes in the SVG viewer panel.

This video I followed shows “slur shapes” being tweaked in Denemo.

https://vimeo.com/64408182

Inkscape can also be used in command line mode to tweak objects and I will explore this later. (See Process Pallette below)

One note of caution. Such tweaks in the end images do not reflect back into the original markdown source and it would be better to learn to tweak at markdown level, and not at SVG level.  This will guarantee the integrity of your workflow should you need to reverse any steps and later recompile your markdown.

Quote
Now, I think it will probably take me a year to get really up to speed with Lilypond, and by that time perhaps you will have your Markdown-to-Scribus pipeline in place.

That is a reasonable timeframe for your book project. I hope to develop the Atom-Scribus pipeline rather sooner for my own purposes. I will release that after testing.  This exercise in music notation does help as a test data set.

Quote
Atom itself is more difficult to get simply because it has a bewildering number of capacities

That is true and the trick is to vet the library of packages to see what mix might apply to each user's workflow.

I realise that there are different classes of Scribus user following this forum. Some are authors only who do not wish to dabble in programming and some are authors and developers confident to expand their toolbox. Perhaps when posting questions the original poster (OP) should be asked to give a profile to avoid receiving deep technical replies.

The DOS command apm list is useful. Explore the “featured” packages in Atom.

In your developing project there will be many points where you put an action or tweak "on hold" for another day. I found the package TODO to be very useful for the purpose of coming back to reminders embedded in each project file.

Basically you can drop a trigger phrase inside any markdown file and this package will hunt through your files to locate all // TODO statements. There are many found in LilyPond snippets repository, which TODO picks up.

Here is an example:

// TODO: must tweak this score before publishing


Quote
I was interested to find that I can run "apm install *package*" from the command line without Atom being open.

apm is alias for Atom Package Manager which manages all Atom assets through DOS command line.

https://github.com/atom/apm

If you now run the command apm --help you will see a list of other options.

for example run apm help <command> to explore any other option before using.

apm help featured


Quote
I am inclined to go ahead and convert the database that exists, because I can't think of anything important to me that is likely to be in it.

Yes, I agree and think that this message will clear up after you start using project-viewer.

But if you are concerned about corrupting your future project work you should start thinking about a project backup strategy so that you can fall back to earlier project states, including Atom configuration files which might be edited over time.

This explains backing up .atom.
https://discuss.atom.io/t/how-to-backup-settings-packages-and-every-thing/42887

But you will also need to backup your ~/Atom-repo/ contents if you have centralised your project files there as suggested earlier.

There are advanced backup tools which only backup intermediate changes.

I am just starting to learn about Atom backup tools.  If the project is important perhaps creating a private git account or Dropbox account might be prudent and then syncing your local project file with the remote content.

https://discuss.atom.io/t/how-to-backup-settings-packages-and-every-thing/42887

Quote
I have a shortcut to the old DOS command line window

That requires jumping out of Atom world.  There is another useful Atom Community Package

terminal-tab

which launches a terminal inside Atom (location can be set in package Settings).
It is always a good idea to become familiar with these Settings after installing any new package.

terminal-tab opens by default below the editor panel.

===========================================

Process Palette Package

Edit: I came back to read this section again and decided I needed to edit it since it is tricky package to use for the first time user.

While terminal-tab is useful for one off commands, a much more comprehensive package for building a library of custom commands is process-palette.

https://atom.io/packages/process-palette

This package allows a custom library of shell (or DOS) commands to be built up by the user.  This will come into use when we learn later that there is more to lilypond than just the basic package lilypond:compile. Indeed, I was surprised that the Atom package lilycompile has not (yet) been extended to take full advantage of the LilyPond commands available.

The lilycompile package README.md does explain that it is a single command package.

“Comes with one configurable command, lilycompile:compile (ctrl-alt-l), which only triggers in .ly files.”

If you inspect lilycompile Settings > Binary there is only one command available.
Default: lilypond

I searched my Linux filesystem looking for the pattern bin/lily
and I found these (all command line executables in bin folder):

/usr/bin/lilymidi
/usr/bin/lilypond
/usr/bin/lilypond-book
/usr/bin/lilypond-invoke-editor
/usr/bin/lilysong

Paths for Windows will differ.

Now we already know that lilypond converts *.ly files to *.svg (or pdf, jpg, ps).
This is the single command used by lilycompile package.

But I have learned from browsing the LilyPond site that lilypond-book converts *.lytex files (not *.ly files) into merged text and scores as a "lilybook" as explained here.

http://lilypond.org/doc/v2.19/Documentation/usage/an-example-of-a-musicological-document

I do not see that it is an easy process to extend the lilycompile package to leverage lilypond-book. Instead I decided to use package Process Palette to exploit the full scope of LilyPond commands.

Running this example ...

http://lilypond.org/doc/v2.19/Documentation/usage/an-example-of-a-musicological-document

I read that the command to run is ...

lilypond-book --output=out --pdf lilybook.lytex

In command terminal this should compile lilybook.lytex as pdf.

However in Atom the command must be changed to run the file in focus in editor which is defined by the Atom variable {filePath}

lilypond-book --output=out --pdf {filePath}

Navigate to Packages > Process Palette > Settings

We read that we must edit process-palette.json to create a library of custom commands.

Note: In the lilybookexample there is a line referring to screech-and-boink.ly

Comment out this line with a % at start of line
to avoid errors in compilation.


Now we require to add a custom command to compile the file lilybook.lytex

Navigate to Edit > Configuration > Settings > Packages > Process Viewer > Toggle.
A Process Palette window will appear underneath the editor centre window.
Click on “Help” button at top (resembles a cog wheel).

There are two options seen:

  • ~/.atom folder for global commands [Doit button]
  • root of any of your project folders for project specific commands [Doit button]

Clicking on [Doit button] places a process-palette.json in either global location or local project location.

After loading a configuration file the command Process Palette: Reload Configuration is run to load it.

The list of Process Palette commands can be seen by launching Command Palette [Ctrl+Shift+P].

Or you can go to Packages > Command Palette > Toggle .. and type Process Palette.

...

This lists all the available Process Palette commands.

Choose Process Palette: Edit Configuration

...

The Graphical Editor to add commands might be tricky to spot at first usage.

When the Process Palette panel appears there is a Global title with a list of commands underneath.

In any command definition starting from the left is

a run button
an edit button
and then the name given to the command.

Click on the edit button and the editor appears above with title Global Commands.

There is a list of created custom commands (there will be at least one example on first usage of package).

Click on "add" and a GUI pops up for the custom command creation.

General
Namespace: process-palette
Action Name:   we might specify here ... lilybook-compile-pdf
Shell Command:  we write here the command to be run
Working Directory:   we write here the working directory
Menu: optionally the command might be added to Menus

The completed custom command will appear under Global Commands.

This is the basic first test command inserted to experiment with lilybook (we will learn later that this command needs to be expanded to tidy up surplus files created in /out folder during compilation).

lilypond-book --output=out --pdf {filePath}

Now we can create a lilybook.lytex file, focus on the file and with the Process Palette window viewed underneath select command: Process Palette: Lilybook Compile Pdf
and run process.

The command output will show as in a terminal.

To go back to Process Palette panel click on the button with three horizontal bars at top

The compiled output files are placed in an /out directory within the project root folder.

Reading the guide here ...

http://lilypond.org/doc/v2.19/Documentation/usage/an-example-of-a-musicological-document

under Processing, the command
pdflatex lilybook
has to be added to the original command to clear out unwanted files.

I ran that command on the /out folder and the outcome is lilybook.pdf.

Click on the created pdf file and we see them in pdf-view.
We can also delete the entire /out folder to purge all experiments and re-compile to see it being reinserted.

This is what is created in configuration file:-

Code: [Select]
    {
      "namespace": "process-palette",
      "action": "lilybook-compile-pdf",
      "command": "lilypond-book --output=out --pdf {filePath}",
      "arguments": [],
      "cwd": null,
      "inputDialogs": [],
      "env": {},
      "keystroke": null,
      "stream": true,
      "outputTarget": "panel",
      "outputBufferSize": 80000,
      "maxCompleted": 3,
      "autoShowOutput": true,
      "autoHideOutput": false,
      "scrollLockEnabled": false,
      "singular": false,
      "promptToSave": true,
      "saveOption": "none",
      "patterns": [
        "default"
      ],
     

The summary is that we now have a powerful package to extend Atom by adding custom commands. This will come in handy for many command line jobs such as running lilypond, lilypond-book, and pandoc commands.

===========================================

Concluding:

There is a continent of Packages to explore in Atom framework and for a newcomer (particularly a non-developer) early returns should not be expected.

But as you wrote here .. http://forums.scribus.net/index.php/topic,3021.0.html

"Slow, maybe, but you know, water wears away the stone".
 
Atom is a diamond tipped tool to sculpt the stone.

Good luck with your projects. The test case has proven to be interesting.
53
Linux / Re: Weird ux scale when installing scribus 1.5.3 on debian 9
« Last post by a.l.e on September 14, 2018, 12:11:54 pm »
i started thinking about writing a bug report for this... and while looking at my screen i somehow understood why this issue does not really bother me:



it's a informal good practice to remove all toolbars but the "tools" one (the "real" toolbar : - ) and put it on the left side of the monitor.

among the other toolbars, the only one that is sometimes useful it's the pdf one (and it's only useful if you're creating interactive pdfs).
the command in the other ones can be better reached through the shortcuts or the menus.

i still think, that the buttons could be half as big (at least optionally), but "correctly" configuring scribus will help you getting along : - )
54
Linux / Re: Weird ux scale when installing scribus 1.5.3 on debian 9
« Last post by a.l.e on September 13, 2018, 10:53:38 pm »
what do you mean by low resolution?
that the icons are big?

yes, some of the icons are now too big here too...
it's probably related to the support of high resolution monitors and afaik that part is still not finished...
55
Beginner Talk / Re: nudging
« Last post by a.l.e on September 13, 2018, 10:51:41 pm »
yes, if i use mm as the units, then i get the movement as specified in the your post (and probably the manual).

concerning the inches, if there is a difference between the current behavior and the manual, the question is which of both is the correct one.
i can confirm that what you describe seems to be what happens.

you might want to submit a bug report to https://bugs.scribus.net to get one of both (you can pick the one that seems to be more useful...) to be fixed.

i don't know if you can modify the key bindings (probably not), but in scribus 1.4 you can change the current unit with the selector in lower left corner...
56
Since I am a simple-minded idiot, it always takes me a while to figure out what Dragonfly is talking about, but he knows a lot of useful stuff and has advised me well.

However, I say that it would be perfectly possible, in the case of your encyclopedia to paste the images in one by one, place an individual text box next to each one, and write or paste the caption and text into the text box. That's how I would do it without any fancy programming or automation. (I don't think that you could do this satisfactorily with one big text block). My method would take some time, but no special skills.

Now, with 400 images if there is one to the page, that's 400 pages, and Scribus in my experience so far does not work well with such large files, and so I would break it up into 26 files, one for each letter, and use the document setup to start each section's page numbering after the last page numb of the previous. Then export to 26 pdfs, merge the pdfs with a pdf tool, and you have a book.

I myself am working on Dragonfly's recommended workflow with Atom and Markdown, but I am new to it. Before getting into it, I had already almost completed a major book project using the most primitive methods, more or less as I recommend above: put the image on the page, put a text box next to it, and type or paste the text into Story Editor. Slow, maybe, but you know, water wears away the stone.
57
Beginner Talk / Re: nudging
« Last post by jack_cat on September 13, 2018, 07:37:04 pm »
My workaround for this has been to use "control plus-sign" (as many times as necessary usually twice) to zoom in on the work space, and then I can move objects in smaller increments (by dragging with the mouse if the nudge is still too coarse?) - I am not sure if zooming in actually changes the arrow-key nudge distance which is probably in pixels and changes relative to the zoom? - I would have to do a controlled test, but zooming in does improve my ability to see what I'm doing, and things can be moved with the mouse too. I hadn't thought of it as a problem, I just zoomed in the first time I ran into it. I can set a guide, for instance, to align several separate items to, and then zoom in and adjust them all to the guide even though I can only see a little bit of the workspace. For text, it helps to set the style to "align to baseline grid" so that the text boxes don't have to align exactly horizontally, in the case of side-by-side text boxes. For vertical alignments to a guide, just zoom in. Then "control minus-sign" to zoom out again.

FYI "to nudge" is to poke the person next to you in the ribs (lightly) with your elbow when you want to draw their attention and it wouldn't do to talk about it out loud - it is intended to be a surreptitious gesture. The OED reports first use in 1675. From there it went to "pushing heavy furniture into place" by an inch or so, and thence somehow into computer slang? Nudging a text box around. Whatever.
58
Beginner Talk / Re: Fonts in font preview but not available in styles
« Last post by jack_cat on September 13, 2018, 07:07:40 pm »
When I started to work with Scribus, I found out that the font I had been intending to use didn't work in Scribus - I forget exactly what the issue was, something like some of the font subsets worked but the bold didn't - and Google turned up info in the Scribus documentation that had a whole song and dance about font compatibility, together with a request for user feedback on what fonts worked or didn't work in Scribus, and after reading that I decided not to fight it and to just change to another font, which turned out to work. If a font doesn't work in Scribus, find another similar one and try it out in a test doc.sla. Pros buy fonts, but I don't. There are a lot of free fonts out there that are not pro quality, is what I found out, and Scribus being aimed at pro quality output is picky, perhaps arbitrarily, about fonts. Not for us non-programmers to reason why or figure out. 
59
Beginner Talk / Re: Joining many .sla in to one file
« Last post by jack_cat on September 13, 2018, 06:44:15 pm »
I have a draft of a book in which the different chapters are in different .sla files. I copy the styles and master pages to all - I have learned to make a template doc with the styles and master pages which I open and do "save as" when I start a new chapter.
In the doc setup menu, I can set the starting page number for each chapter. This would work with any project divided into reasonable sections. 
Then I export each chapter individually to pdf and use a pdf-editing tool to merge the pdfs into one. The resulting merged PDF is fine to print from.

My only complaint is that when I copy anything from one of these files into another (say I decide something belongs in a different chapter) it imports the same styles from the other doc (all the styles being the same) and re-names them Style-1_copy (etc.) and so, if I do much of this, pretty soon I have to edit the styles and get rid of all the duplicates. So I copy first to a text editor which strips the styles out and then recopy into Scribus, an extra step, but it saves the time and annoyance of editing the styles all the time.

Trying to merge all the files within Scribus is something I have had no luck with because anything over about 40 pages takes too much memory for my computer. There are plenty of weird buggy things in Scribus (but the primary functions all work fine and well enough that I don't complain much) but so far I have found my own workarounds for everything, one way or another (even if time-consuming), and I respect the fact that it is a work in progress, free, generous, and not perfect, and if there are a few things that are broken or don't work right, it makes sense to look for the most immediate workaround and just do it.
60
Beginner Talk / Re: Parallel text for a bilingual book
« Last post by jack_cat on September 13, 2018, 06:28:14 pm »
Given that all of the left pages have a text box linked to the preceding and following left pages, and the same for the right pages in the other language, all you do to sync the two flows is, whichever language is running ahead of the other one because of using fewer words or characters, is pull the bottom of that text box up with the mouse, using the red handle at the bottom of the box, so that the text overflow is forced to the next page, and it should be easy to have at least the first paragraph across the top of the two pages synced. Then, within the page, if one language is running ahead of the other, a few extra line breaks in the shorter file should sync the beginnings of subsequent paragraphs down the page. Did I understand the question right? That's how I would do it.
Pages: 1 2 3 4 5 [6] 7 8 9 10