PrintSky plugin

[gzotti]

This is a rebased reactivation of Pep Pujol's PrintSky plugin which had been abandoned in 2010.

Description

I have rebased the PrintSky branch left abandoned in 2010. It was still on Qt4, so I updated necessities to Qt5 and (2022) to Qt6, property handling etc.

After all, a printed report (PDF or real printer) can become helpful.

However, we currently don't really know what a "printed report from Stellarium" should look like. I therefore invite fellow developers to come forth with an idea, maybe an "astro club information sheet" for street astronomy of "what to see tonight", or anything else. Maybe a solution with a few templates. Usually we just make screenshots and embed them in other documents.

Fixes #410 (issue)

Currently preview works, but storing to PDF crashes. Page layout is a mess. It really needs a thorough redesign.

New Features checklist

Before merge, IMHO at least most of these should be done. Please feel free to add more (reasonable) ideas.

• sorting the ephemeris list (planets first, then their moons (or maybe moons sorted with the planets?), then asteroids, then comets. By name or by date of perihelion?
• Comets: Respect orbit_good values! (Suppress comets far from perihel)
• Some more general info on page 1: maybe sunrise/sunset, eq. of time, twilight times, moon details? But esp. details for selected object.
• Add a magnitude limit
• Better magnitude scale
• respect configured custom screenshot size (aspect ratio!)
• add header/footer with date and Stellarium icon, name and version number, and page number

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 10
• Graphics Card: NVidia GeForce M960 (irrelevant)

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[alex-w]

Hmm... Should we merge this PR into master and propose users to testing?

[gzotti]

Hmm, this was so far just a fast port to make it work again. We should put some more effort into it before public testing, or else we get the most obvious points as feedback, see (edited) feature proposal checklist in the description.

Maybe we can implement at least some of these by ~ September 5, then merge and run for public testing?
It may be possible to combine that with "ephemeris generator" methods from AstroCalc. Is it possible to get the curves from AstroCalc into the report?

There are traces of "dynamic plugin" still in here. Maybe experiment to revive that idea?

[alex-w]

Hmm, this was so far just a fast port to make it work again. We should put some more effort into it before public testing, or else we get the most obvious points as feedback, see (edited) feature proposal checklist in the description.

Some points from the list look strange to me (and it was strange since the birthday of plugin) - for example we shot some part of the sky and attached ephemerides of Solar system objects, but these parts are not related together. We can get a situation, when a screenshot will have no one solar system object.

Maybe we can implement at least some of these by ~ September 5, then merge and run for public testing?

I guess the screenshot should be with an equatorial grid to allow users to navigate on the printed map (on the other hand it will be not very good for dobsonian telescopes owners). Plus we can add some magic to remove halo around stars and replace color of the sky on the screenshots to get a map, similar to map from atlases.

Maybe we should ask potential users on the forums like Cloudy Nights and Stargazers Lounge?

It may be possible to combine that with "ephemeris generator" methods from AstroCalc. Is it possible to get the curves from AstroCalc into the report?

See QVector Ephemeris List and Ephemeris struct - we can attach an ephemeris of object (or few objects), if those data are calculated. See: STELLARIUM REPORT.pdf and STELLARIUM REPORT inverted.pdf

There are traces of "dynamic plugin" still in here. Maybe experiment to revive that idea?

See https://github.com/Stellarium/stellarium-dynamic-plugin - it works on linux, but I fear it will not work for Windows

[gzotti]

Some points from the list look strange to me (and it was strange since the birthday of plugin) - for example we shot some part of the sky and attached ephemerides of Solar system objects, but these parts are not related together. We can get a situation, when a screenshot will have no one solar system object.

The ephemeris is an optional element. I added a place for "information about the currently selected object", but it does not show anything yet. I think it should be easy to output InfoString here (Maybe even something else, later), but I don't know yet how to manage a pagebreak or pretty-print HTML. Of course, this should be printed only if there is a selection.

I guess the screenshot should be with an equatorial grid to allow users to navigate on the printed map (on the other hand it will be not very good for dobsonian telescopes owners). Plus we can add some magic to remove halo around stars and replace color of the sky on the screenshots to get a map, similar to map from atlases.

This would require changes in the screenshot creation. You can set the screen background color (light-blue background if you prefer?), and certainly plain round white stars. But this is not even urgent, IMHO. I would leave selection of grids and most other choices about the screenshot appearance to the user. But probably we must force a screenshot size or dimensions to fit image and text on one layout, and we must combine landscape/portrait, and when Qt has the options, should probably support A4 and letter paper. It is possible that the star magnitude scale and any rescaled screenshot currently don't fit together. We need to experiment with manually scaled screenshots e.g. at the usual scale of 72 pixels/inch. (Maybe go to 144 or 216px/in and scale star mag scale instead?)

Maybe we should ask potential users on the forums like Cloudy Nights and Stargazers Lounge?

If there is a developer there, who knows himself what best to develop? Else you are asking for more work.

It may be possible to combine that with "ephemeris generator" methods from AstroCalc. Is it possible to get the curves from AstroCalc into the report?

See QVector Ephemeris List and Ephemeris struct - we can attach an ephemeris of object (or few objects), if those data are calculated. See: STELLARIUM REPORT.pdf and STELLARIUM REPORT inverted.pdf

Of course the ephemeris curve plotted in the map can be shown. I meant e.g. curves like magnitude and diameter over a whole year.

There may be several modes of reports which we could specify before we implement more:

• General "screenshot without selected object". Like now, has image (optionally inverted), location and twilight info, star scale, and optional SSE position info. Maybe add DSO in field of view?
• "Selected object info" like your Ceres map. For SSO, should have positional ephemeris for some configurable time (or whatever is currently configured in AstroCalc). For DSO, just all details (InfoString).
• For DSO finder charts, it may be useful to not show today's twilight or other temporal information.

There are traces of "dynamic plugin" still in here. Maybe experiment to revive that idea?

See https://github.com/Stellarium/stellarium-dynamic-plugin - it works on linux, but I fear it will not work for Windows

See StelDialogPrintSky.hpp, it mentions Windows explicitly.

I have no time today, maybe in the evening.

[gzotti]

@alex-w please we should rebase this branch from master, not merge master, to have a cleaner history. Basically, while a branch is draft, this should be necessary only when then some progress can be expected.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.