gnuplot-beta — Developers and beta testers of new gnuplot code

Re: setting "enhanced" for individual elements of a plot

[Jeremy N. - ml g. <jn....@wi...>]

On 2025-05-09 00:47, Ethan A Merritt wrote:

> As it stands now, the terminal driver API provides only one entry point 
> for
> sending text.  When the terminal is initialized, this entry point is 
> either
> set to the enhanced text routine or to the plain text routine.
> The "noenhanced" attribute works by temporarily setting a global flag
> that can be seen by the terminal's enhanced text routine [see below].
> If the flag is set, the terminal just ignores all the markup 
> characters.
> Going the other way is I suppose possible, but would require new code
> in the plain text routine that knows to check some flag or other global
> condition and redirect the call to the enhanced text routine instead,
> possibly having to deal with initiallization of state variables
> (mostly font-related stuff) that would otherwise have been done
> when the terminal was first set to enhanced text mode.

If the state vars are only used by the enhanced mode then maybe you 
could
sometimes initialise the terminal twice?  That is, first always 
initialise
the enhanced routine (to do the font stuff etc), then as if that had not
been done (but only if noenhanced was set initially) initialise the 
plain
text routine?  Would that leave plain-text in effect exactly as it works
now, but mean that temporary switches into enhanced would work?


-- 
Jeremy Nicoll - my opinions are my own

Re: setting "enhanced" for individual elements of a plot

[Ethan A M. <me...@uw...>]

On Thursday, 8 May 2025 08:11:12 PDT Cottrell, Allin via gnuplot-beta wrote:
> In some contexts I prefer to set "noenhanced" as an initial terminal
> option (to avoid turning underscores in identifiers into subscript
> markers), but show certain labels in enhanced mode. The doc for (e.g.)
> xlabel says "noenhanced requests that the label text not be processed
> by the enhanced text mode parser, even if enhanced text mode is
> currently active." That works fine, but I'm looking for the converse,
> namely (e.g.)
> 
> set xlabel "s = λ/λ_{max}" enhanced
> 
> when noenhanced has been set initially, and that doesn't work, or at
> least not with gnuplot 6.0 p2. Would it be difficult to support?

I think it would be difficult, or at least tedious.
At the very least it would require new code in every terminal driver that
supports enhanced text.

As it stands now, the terminal driver API provides only one entry point for
sending text.  When the terminal is initialized, this entry point is either
set to the enhanced text routine or to the plain text routine.
The "noenhanced" attribute works by temporarily setting a global flag
that can be seen by the terminal's enhanced text routine [see below].
If the flag is set, the terminal just ignores all the markup characters. 
Going the other way is I suppose possible, but would require new code
in the plain text routine that knows to check some flag or other global
condition and redirect the call to the enhanced text routine instead,
possibly having to deal with initiallization of state variables
(mostly font-related stuff) that would otherwise have been done
when the terminal was first set to enhanced text mode.    

Use of a global flag was a hack to minimize change to the core code
back when enhanced text mode was extended to be a general option
rather than a special feature of the PostScript terminal.   In retrospect
it might have been better to accept the pain of changing the terminal API.
In any case if we were to aim for flipping enhanced text on and off as
you suggest, I think it would be time to change the API by adding a
term->enhanced_mode(TBOOLEAN state) entry point that the core
routine write_label() could use rather than dealing with multiple
global flags that violate the API boundary between the core code
and the terminal code.

    Ethan Merritt


> 
> Allin Cottrell


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

setting "enhanced" for individual elements of a plot

[Cottrell, A. <cot...@wf...>]

In some contexts I prefer to set "noenhanced" as an initial terminal
option (to avoid turning underscores in identifiers into subscript
markers), but show certain labels in enhanced mode. The doc for (e.g.)
xlabel says "noenhanced requests that the label text not be processed
by the enhanced text mode parser, even if enhanced text mode is
currently active." That works fine, but I'm looking for the converse,
namely (e.g.)

set xlabel "s = λ/λ_{max}" enhanced

when noenhanced has been set initially, and that doesn't work, or at
least not with gnuplot 6.0 p2. Would it be difficult to support?

Allin Cottrell

Re: [PATCH 0/3] SVG terminal enhancements: Title, Description, and Escaping

[Ethan A M. <me...@uw...>]

On Friday, 11 April 2025 21:02:54 PDT Fredrick R. Brennan wrote:
> Hello Gnuplot developers,
> 
> This patch series introduces three small enhancements for the SVG 
> terminal driver aimed at improving metadata, accessibility, and 
> robustness of the generated output.

Applied. Thanks.

> 
> Patch 1/3 ([svg] add > for > in ENHsvg_writec):
> This patch improves enhanced text handling by escaping the > character 
> to >. This prevents rendering issues and XML errors in viewers like 
> Firefox when labels contain this character.
>
> Patch 2/3 ([svg] add plot title to XML <title>):
> This patch makes the SVG <title> element more meaningful, resolving a 
> TODO in the source code. It now uses the Gnuplot plot title (set title) 
> if one is defined, falling back to the name set via set term svg name 
> "...", and finally to "Gnuplot" as a default.
> 
> To handle potentially complex title strings correctly within XML, this 
> patch also introduces a helper function, SVG_put_CDATA, which correctly 
> embeds text within <![CDATA[...]]> sections, including the necessary 
> escaping for the forbidden ]]> sequence.
> 
> Patch 3/3 ([svg] add ability for user to set XML <desc>):
> This patch introduces a new terminal option description "<text>". If 
> this option is used, the provided text is embedded in the SVG <desc> 
> element, allowing users to easily add descriptive metadata or 
> accessibility information to their plots. This patch reuses the 
> SVG_put_CDATA helper function introduced in Patch 2 and includes 
> documentation for the new option in the terminal help.
> 
> These changes should apply cleanly to the current master branch. Patch 3 
> relies on a function introduced in Patch 2.
> 
> Feedback welcome!
> 
> 
> ------------------------------------------------------------------------
> 
> Best,
> Fred Brennan
> 
> |[[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> 
> GnuPG: 98F2 8F76 7470 129F BE3B 054C E215 4DD1 A1C7 7B8B
> BlueSky: @copypaste.bsky.social
> Personal website: <https://ctrlcctrlv.github.io/>
> 
> 
> 


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: gnuplot 1.0

[Dima K. <gn...@di...>]

I just read the docs (git fetch --help). I think the key line is

  By default, any tag that points into the histories being fetched is
  also fetched; the effect is to fetch tags that point at branches that
  you are interested in. This default behavior can be changed by using
  the --tags or --no-tags options

I guess the difference here is that the new "1.0" tag is in a separate
tree, disconnected from the rest of it, so you need to ask for the tags
explicitly. I had no idea this was a thing. In any case, this is
probably fine for a historical thing.

Re: gnuplot 1.0

[Ethan A M. <me...@uw...>]

On Sunday, 6 April 2025 15:11:47 PDT Dima Kogan wrote:

> Did you push the tag already (git push --tags)? I don't see it in the
> main repo.

Yeah, I was going to ask you about that.
I pushed it.
It's there.
I can see it on SourceForge.
But in order to pull it I need to do
    "git pull --tags"
The extra option isn't needed in other cases, so why now?

   Ethan

Re: gnuplot 1.0

[Dima K. <gn...@di...>]

> Thanks.   I messed up a couple of times but eventually got it.  I think.

Did you push the tag already (git push --tags)? I don't see it in the
main repo.

Re: gnuplot 1.0

[Ethan A M. <me...@uw...>]

On Friday, 4 April 2025 09:59:31 PDT Dima Kogan wrote:
> 
> Ethan A Merritt <me...@uw...> writes:
> 
> > [~/git/gnuplot-main] git checkout --detach 1.1
> > HEAD is now at 2f87cf77c Content from historic/gnuplot-1.1.tar.gz
> > =========================================================
> >
> > But I have no idea how to add this version 1.0 snapshot to the
> > repository so that it matches the others. Does anyone know an
> > appropriate set of git commands?
> 
> If you insert the new 1.0 code into the tree, that will change all the
> commit IDs downstream of it (i.e. everything we're actively working on
> now). So I'd add 1.0 by itself in its own root. So 1.1 wouldn't be a
> child of 1.0, but since this is all for historical archiving, that
> doesn't really matter.
> 
> You can do this by
> 
> - Creating a brand-new repo (let's say in /tmp/gnuplot1), and adding the
>   gnuplot 1.0 code and the "1.0" tag there
> 
> - In your main gnuplot tree, add this as a remote
> 
>   git remote add gnuplot1 /tmp/gnuplot1
>   git fetch gnuplot1
> 
> Now the "1.0" tag has been ingested into your tree, and if you "git push
> --tags", you'll send all your tags (including this one) to sourceforge.
> That's it.

Thanks.   I messed up a couple of times but eventually got it.  I think.

   Ethan

Re: image or rgbimage plots with zero decorations

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> I would have thought the heart of it would be
>     set autoscale noextend 
>     set margins 0,0,0,0

Oh wow. That actually does 99% of what I want. Thank you!

The extra 1% is probably a bug: I have this script:

  set margin 0,0,0,0
  unset xtics
  unset ytics
  set terminal png size 1027,1035
  set output "/tmp/tst.png"

  plot "/tmp/input.png" binary filetype=png with rgbimage notitle

where the requested png size is the dimensions of /tmp/input.png. If I
look at the input and output side by side, I see the image shift by 1
pixel in each direction.

Thanks for the suggestion.

Re: image or rgbimage plots with zero decorations

[Ethan A M. <me...@uw...>]

On Friday, 4 April 2025 10:32:41 PDT Dima Kogan wrote:
> Hi. I'm pretty sure this isn't possible, but I'd like to ask anyway.
> 
> I have a gnuplot script to plot an image, with some extra stuff on top
> of it. Something like this:
> 
>   set terminal png
>   set output "out.png"
>   plot "image.png" binary filetype=png flipy with rgbimage, "data" with lines
> 
> Ideally I would like the result to be a .png file with the same
> dimensions as "image.png", and I would like "image.png" to fill the
> whole output plot. I.e. I want to annotate "image.png", but not scale it
> in any way.
> 
> There are some options that help somewhat, but don't do everything:
> 
>   set autoscale noextend
>   set size ratio -1

I would have thought the heart of it would be
    set autoscale noextend 
    set margins 0,0,0,0

I think using "set size ratio" is counter-productive for this purpose.

	Ethan
 
> In practice, what I end up doing is to manually find the pixel size for
> the "set terminal png" command that results in the output image of the
> correct size, and then I crop "out.png". Is there a better way?
> 
> Thanks.

image or rgbimage plots with zero decorations

[Dima K. <gn...@di...>]

Hi. I'm pretty sure this isn't possible, but I'd like to ask anyway.

I have a gnuplot script to plot an image, with some extra stuff on top
of it. Something like this:

  set terminal png
  set output "out.png"
  plot "image.png" binary filetype=png flipy with rgbimage, "data" with lines

Ideally I would like the result to be a .png file with the same
dimensions as "image.png", and I would like "image.png" to fill the
whole output plot. I.e. I want to annotate "image.png", but not scale it
in any way.

There are some options that help somewhat, but don't do everything:

  set autoscale noextend
  set size ratio -1

In practice, what I end up doing is to manually find the pixel size for
the "set terminal png" command that results in the output image of the
correct size, and then I crop "out.png". Is there a better way?

Thanks.

Re: gnuplot 1.0

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> [~/git/gnuplot-main] git checkout --detach 1.1
> HEAD is now at 2f87cf77c Content from historic/gnuplot-1.1.tar.gz
> =========================================================
>
> But I have no idea how to add this version 1.0 snapshot to the
> repository so that it matches the others. Does anyone know an
> appropriate set of git commands?

If you insert the new 1.0 code into the tree, that will change all the
commit IDs downstream of it (i.e. everything we're actively working on
now). So I'd add 1.0 by itself in its own root. So 1.1 wouldn't be a
child of 1.0, but since this is all for historical archiving, that
doesn't really matter.

You can do this by

- Creating a brand-new repo (let's say in /tmp/gnuplot1), and adding the
  gnuplot 1.0 code and the "1.0" tag there

- In your main gnuplot tree, add this as a remote

  git remote add gnuplot1 /tmp/gnuplot1
  git fetch gnuplot1

Now the "1.0" tag has been ingested into your tree, and if you "git push
--tags", you'll send all your tags (including this one) to sourceforge.
That's it.

To make it easier, I made the gnuplot1 repo, and pushed it here:

  https://github.com/dkogan/gnuplot1.git

so all you need to do is

- git remote add gnuplot1 https://github.com/dkogan/gnuplot1.git
- git fetch gnuplot1

That's it

Re: Documentation error?

[Ethan A M. <me...@uw...>]

On Thursday, 3 April 2025 09:59:14 PDT Erik Luijten wrote:
> Hi,
> 
> I just noticed a mismatch between the documentation and an actual command.
> For time data, the documentation refers to "set xtics timedata", whereas
> the actual command is "set xtics timedate". 

Thanks.
Corrected now for 6.0 and 6.1

> You can try this within gnuplot:
> 
> gnuplot> help set xtics timedate
> 
> Sorry, no help for 'set xtics timedate'
> 
> 
> Conversely, "help set xtics timedata" works, and then produces
> documentation for "set xtics timedate".
> 
> 
> I believe the website documentation contains the same mismatch, but I
> cannot check this at the moment since it is not accessible.
> 
> 
> Best,
> 
> 
> Erik
> 


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Documentation error?

[Erik L. <eri...@gm...>]

Hi,

I just noticed a mismatch between the documentation and an actual command.
For time data, the documentation refers to "set xtics timedata", whereas
the actual command is "set xtics timedate". You can try this within gnuplot:

gnuplot> help set xtics timedate

Sorry, no help for 'set xtics timedate'


Conversely, "help set xtics timedata" works, and then produces
documentation for "set xtics timedate".


I believe the website documentation contains the same mismatch, but I
cannot check this at the moment since it is not accessible.


Best,


Erik

Re: gnuplot 1.0

[Ethan A M. <me...@uw...>]

On Wednesday, 2 April 2025 17:52:48 PDT Shigeharu TAKENO wrote:

> shige 04/03 2025
> ----------------
> 
> Old gnuplot-1.1 is in SouceForge site. I found historical old 
> gnuplot 1.0 (1.0.3).
> 
> I make the archive file of them (.tar.Z) 
> 
>  http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gnuplot-1.0.tar.Z
>

Very nice code archaeology.  Congratulations.

I don't have a version of gcc old enough to compile it with without
providing a compatibility header and hacking a couple of lines that
refer to obsolete error handling, but after that the *.c files compile
with only a few complaints!

I will add the tarball to the gnuplot-historical directory on SourceForge.
It would be nice to also add it to the git repository, but ...

When  Eric Raymond helped create our current git repository from a combination
of the cvs content and historical tarballs of earlier versions he made it so that
each of the historical version was present as a tag.  I can check each one
out by name for inspection.  Like this:

=========================================================
[~/git/gnuplot-main] git tag
1.1
1.10A
2.0
3.0
3.1
3.2
3.5
3.7.1
3.7.2
3.7.3
... etc

[~/git/gnuplot-main] git checkout --detach 1.1
HEAD is now at 2f87cf77c Content from historic/gnuplot-1.1.tar.gz
=========================================================

But I have no idea how to add this version 1.0 snapshot to the repository
so that it matches the others.
Does anyone know an appropriate set of git commands?


> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

gnuplot 1.0

[Shigeharu T. <sh...@ie...>]

shige 04/03 2025
----------------

Old gnuplot-1.1 is in SouceForge site. I found historical old 
gnuplot 1.0 (1.0.3).

announce: https://usenet.trashworldnews.com/?thread=114748
1/6: https://usenet.trashworldnews.com/?thread=114473
2/6: https://usenet.trashworldnews.com/?thread=114532
3/6: https://usenet.trashworldnews.com/?thread=114531
4/6: https://usenet.trashworldnews.com/?thread=114530
5/6: https://usenet.trashworldnews.com/?thread=114529
6/6: https://usenet.trashworldnews.com/?thread=114528

I make the archive file of them (.tar.Z) 

  http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gnuplot-1.0.tar.Z

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Development binaries for windows are moved

[Tatsuro M. <tma...@ya...>]

Development binaries site for windows has been moved

Development version:
Windows binaries built by Tatsuro Matsuoka: http://ss009322.stars.ne.jp/gnuplot_bin.html (http://tmacchant33.starfree.jp/gnuplot_bin.html)

Tatsuro

Resolved: Gnuplot with Qt terminal on macOS

[Erik L. <eri...@gm...>]

Dear all,

Since the topic of Qt on macOS has come up repeatedly on this mailing list,
I am glad to report that static binaries (which I focus on to make sure
that installation packages are self-contained) for gnuplot 6.0.2 and the Qt
terminal are available now. Executables for Intel- and ARM-based Macs can
be found at
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS

Please do not hesitate to report any problems.

While on the topic of Qt. I hope this is not a silly question, but am I
correct that the buttons with the magnifying glass and a +/– sign do not do
what I would expect (namely zoom in/out)? Instead, they seem to serve to go
to the next/previous zoom level, IF one has already gone through a sequence
of zoom steps using the + key. At first, this seemed so odd that I assumed
it was a problem with Qt on macOS, but I now confirmed that on Linux
gnuplot + Qt works the same way. Am I missing something?

Kind regards,

Erik

Re: Static compilation with Qt

[Erik L. <eri...@gm...>]

Hi, I did solve the second problem, I believe. In
src/qtterminal/gnuplot_qt.cpp, immediately prior to the line


QtGnuplotApplication application(argc, argv);

one needs the line:

Q_IMPORT_PLUGIN(QCocoaIntegrationPlugin);



As far as I can tell, other platforms would need a similar line if one
wishes to build a static binary. For Qt6, the list is here:
https://doc.qt.io/qt-6/qpa.html

Erik


On Wed, Mar 19, 2025 at 3:28 PM Erik Luijten <eri...@gm...> wrote:

> Dear all,
>
> I am trying to create gnuplot executables for macOS in which the Qt
> libraries are statically linked. It is easy to create static versions of
> Qt, but I run into two problems:
>
>
> 1. Compilation of gnuplot on macOS relies on pkg-config, but to the best
> of my knowledge, pkg-config is not supported in Qt6 (if I am mistaken, I
> would be grateful for pointers).
>
>
> 2. Qt5 has support for pkg-config. A regular (dynamic) binary of gnuplot
> works well with Qt. However, a statically compiled version of gnuplot
> starts properly, but as soon as I issue the first plot command there is a
> warning:
>
> qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""
>
>
>
> If I restart gnuplot after setting "export QT_DEBUG_PLUGINS=1", I get:
>
> FactoryLoader::QFactoryLoader() ignoring
> "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since
> plugins are disabled in static builds
>
>
> As far as I can tell, the qtterminal source code should have a
> Q_IMPORT_PLUGIN() command to work properly with static compilation, but I
> do not know enough about Qt to be sure.
>
>
> Any help would be appreciated!
>
> Erik
>

Re: Static compilation with Qt

[Dima K. <gn...@di...>]

You don't NEED pkg-config. All it does is give you some compiler flags
and linker flags. You can set those flags yourself, at least until the
pkg-config breakage is resolved. On my box (Debian/sid) I see this:

  dima@shorty:~/projects/gnuplot$ for p (Qt6Core Qt6Gui Qt6Network Qt6Svg Qt6PrintSupport Qt6Widgets Qt6Core5Compat) { pkg-config --cflags $p }
  -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/include/x86_64-linux-gnu/qt6 -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 
  -I/usr/include/x86_64-linux-gnu/qt6/QtGui -I/usr/include/x86_64-linux-gnu/qt6 -DQT_GUI_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 
  -I/usr/include/x86_64-linux-gnu/qt6/QtNetwork -I/usr/include/x86_64-linux-gnu/qt6 -DQT_NETWORK_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 
  -I/usr/include/x86_64-linux-gnu/qt6/QtSvg -I/usr/include/x86_64-linux-gnu/qt6 -DQT_SVG_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt6/QtGui -DQT_GUI_LIB -DQT_CORE_LIB 
  -I/usr/include/x86_64-linux-gnu/qt6/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt6 -DQT_PRINTSUPPORT_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt6/QtGui -I/usr/include/x86_64-linux-gnu/qt6/QtWidgets -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB 
  -I/usr/include/x86_64-linux-gnu/qt6/QtWidgets -I/usr/include/x86_64-linux-gnu/qt6 -DQT_WIDGETS_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ -I/usr/include/x86_64-linux-gnu/qt6/QtGui -DQT_GUI_LIB -DQT_CORE_LIB 
  -I/usr/include/x86_64-linux-gnu/qt6/QtCore5Compat -I/usr/include/x86_64-linux-gnu/qt6 -DQT_CORE5COMPAT_LIB -I/usr/include/x86_64-linux-gnu/qt6/QtCore -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++ 

  dima@shorty:~/projects/gnuplot$ for p (Qt6Core Qt6Gui Qt6Network Qt6Svg Qt6PrintSupport Qt6Widgets Qt6Core5Compat) { pkg-config --libs $p }  
  -lQt6Core 
  -lQt6Gui -lQt6Core 
  -lQt6Network -lQt6Core 
  -lQt6Svg -lQt6Gui -lQt6Core 
  -lQt6PrintSupport -lQt6Widgets -lQt6Gui -lQt6Core 
  -lQt6Widgets -lQt6Gui -lQt6Core 
  -lQt6Core5Compat -lQt6Core 

So you can try to feed in the equivalent for your box.

Re: Static compilation with Qt

[Ethan A M. <me...@uw...>]

On Wednesday, 19 March 2025 13:28:24 PDT Erik Luijten wrote:
> Dear all,
> 
> I am trying to create gnuplot executables for macOS in which the Qt
> libraries are statically linked. It is easy to create static versions of
> Qt, but I run into two problems:
> 
> 
> 1. Compilation of gnuplot on macOS relies on pkg-config, but to the best
> of my knowledge, pkg-config is not supported in Qt6 (if I am mistaken, I
> would be grateful for pointers).

I use pkg-config with Qt6 without problems.

I am aware of two past pkg-config +Qt6 related issues on the linux side.
(1) Fedora breaks down the Qt6 dependencies differently, so we needed to add a 
check in the configure script that picked them all up.  That change is in 6.0.1
     https://sourceforge.net/p/gnuplot/bugs/2705/

(2) There was an Ubuntu packaging error that failed in include the pkg-config files
*.pc in the initial Ubuntu Qt6 packages, and this failure propagated to ubuntu
derivatives like Mint.  I confirmed at the time that (at least on Mint)
it was sufficient to regenerate the *.pc files directly from the Qt repository or
to copy them, after inspection, from another linux distro.  That problem was
acknowledged upstream by Unbuntu, but I have not tracked the resolution since then.
Here is a link to one message in the thread exploring this
    https://sourceforge.net/p/gnuplot/mailman/message/58773575/

I don't know why a Fedora or Ubuntu glitch would affect macOS, but perhaps there was
a parallel failure with the same result. 

> 
> 
> 2. Qt5 has support for pkg-config. A regular (dynamic) binary of gnuplot
> works well with Qt. However, a statically compiled version of gnuplot
> starts properly, but as soon as I issue the first plot command there is a
> warning:
> 
> qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""

I can't help you here. I believe that Cocoa is one of several possible graphics 
backends for Qt on macOS, but if you switch to one of the others you may well
just get the equivalent warning for that new backend.

	Ethan


> 
> 
> If I restart gnuplot after setting "export QT_DEBUG_PLUGINS=1", I get:
> 
> FactoryLoader::QFactoryLoader() ignoring
> "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since
> plugins are disabled in static builds
> 
> 
> As far as I can tell, the qtterminal source code should have a
> Q_IMPORT_PLUGIN() command to work properly with static compilation, but I
> do not know enough about Qt to be sure.
> 
> 
> Any help would be appreciated!
> 
> Erik
> 

Static compilation with Qt

[Erik L. <eri...@gm...>]

Dear all,

I am trying to create gnuplot executables for macOS in which the Qt
libraries are statically linked. It is easy to create static versions of
Qt, but I run into two problems:


1. Compilation of gnuplot on macOS relies on pkg-config, but to the best
of my knowledge, pkg-config is not supported in Qt6 (if I am mistaken, I
would be grateful for pointers).


2. Qt5 has support for pkg-config. A regular (dynamic) binary of gnuplot
works well with Qt. However, a statically compiled version of gnuplot
starts properly, but as soon as I issue the first plot command there is a
warning:

qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in ""



If I restart gnuplot after setting "export QT_DEBUG_PLUGINS=1", I get:

FactoryLoader::QFactoryLoader() ignoring
"org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" since
plugins are disabled in static builds


As far as I can tell, the qtterminal source code should have a
Q_IMPORT_PLUGIN() command to work properly with static compilation, but I
do not know enough about Qt to be sure.


Any help would be appreciated!

Erik

Re: Website doesn't have links to the bug tracker

[Ethan A M. <me...@uw...>]

On Monday, 24 February 2025 10:34:46 PST Dima Kogan wrote:
> Hi.
> 
> Our website:
> 
>   gnuplot.sourceforge.net

> has links to the git repo, but not to the bug tracker or mailing lists
> or anything like that. That stuff lives on the sourceforge project page:

???
I am not 100% certain what you see when you cllck on the "git repo" link.
Perhaps it is browser-dependent, or depends on whether SourceForge recognizes you?
For me it lands on a page where the navigation panel directly below the line with the
gnuplot logo and title "gnuplot Git Repository" looks like this:

  Summary  Files  Reviews  Support  Tickets▾  Git Repository  Mailing Lists Discussion News ...


The Tickets pull-down opens up the bug tracker, feature requests, etc.

I can change the home page to say "git repository and issue tracker".
That's a reasonable idea.
I don't know if there's a better label than "Tickets" for the pull-down menu on the
project page (and for that matter I don't know if I can change it).

>> but that's not linked from our website either. Can we add some links?

I agree it would be good to duplicate that link at the top of the home page.

> Today, filing a bug is non-obvious if you don't already know where the
> tracker is.

Every time one runs gnuplot it starts with the splash page
        G N U P L O T
        Version 6.0 patchlevel 2    last modified 2024-12-04 

        Copyright (C) 1986-1993, 1998, 2004, 2007-2024
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"

gnuplot> help FAQ
[snip]
 Bug reports and feature requests should be uploaded to the trackers at
           https://sourceforge.net/p/gnuplot/_list/tickets
 Please check previous reports to see if the bug you want to report has
 already been fixed in a newer version.
[snip]

    Ethan

Website doesn't have links to the bug tracker

[Dima K. <gn...@di...>]

Hi.

Our website:

  https://gnuplot.sourceforge.net/

has links to the git repo, but not to the bug tracker or mailing lists
or anything like that. That stuff lives on the sourceforge project page:

  https://sourceforge.net/projects/gnuplot/

but that's not linked from our website either. Can we add some links?
Today, filing a bug is non-obvious if you don't already know where the
tracker is.

Thanks

Re: AquaTerm (all solved)

[Erik L. <eri...@gm...>]

Intel version:
https://pergamon.ms.northwestern.edu/Download/Gnuplot/aquaterm-1.1.1p1-x86_64.pkg

These are just intended for testing, e.g. by you, Jun.

Thanks,

Erik


On Sat, Feb 1, 2025 at 8:29 AM Erik Luijten <eri...@gm...> wrote:

> Here is a version for ARM-based Macs, probably requiring Sequoia 15.2 or
> up:
> https://pergamon.ms.northwestern.edu/Download/Gnuplot/aquaterm-1.1.1p1-arm64.pkg
>
> On Sat, Feb 1, 2025 at 8:19 AM Erik Luijten <eri...@gm...>
> wrote:
>
>> Hi Jun,
>>
>> Yes, that resolves the problem! How do we proceed? Ideally, this bugfix
>> should be made in the distribution of AquaTerm. If this is hard, maybe I
>> can distribute compiled AquaTerm packages for ARM and Intel as "1.1.1
>> patchlevel 1" or so.
>>
>> By the way, I have not checked for any unintended side effects in
>> AquaTerm.
>>
>> Best,
>>
>> Erik
>>
>> On Fri, Jan 31, 2025 at 7:06 PM Jun. T <tak...@kb...>
>> wrote:
>>
>>>
>>> > 2025/01/28 7:00, Ethan A Merritt <me...@uw...> wrote:
>>> >
>>> > Also, can someone now check whether Bug #1969 "Aquaterm: plot using
>>> third column for color palette value loses every 2nd line" is still a
>>> problem or can now be closed?   Maybe I should close it anyhow, since the
>>> aquaterm project seems moribund.
>>> >     https://sourceforge.net/p/gnuplot/bugs/1969/
>>>
>>>
>>> > 2025/01/28 7:05、Erik Luijten <eri...@gm...>のメール:
>>> >
>>> > I just checked. The problem still exists (screenshots below). I know
>>> nothing about AquaTerm, so cannot assist in resolving this, unfortunately.
>>>
>>> Could you please try the following patch when building AquaTerm.app?
>>> (I hope it has no bad side effects.)
>>>
>>> Jun
>>>
>>>
>>>
>>> --- AQTPlotBuilder.m.ORG        2012-07-30 23:39:50.000000000 +0900
>>> +++ AQTPlotBuilder.m    2025-02-01 09:10:01.000000000 +0900
>>> @@ -149,7 +149,15 @@
>>>     // FIXME: Use AQTEqualColor instead
>>>     if ((newColor.red != _color.red) || (newColor.green != _color.green)
>>> || (newColor.blue != _color.blue) || (newColor.alpha != _color.alpha))
>>>     {
>>> +      int32_t count_save = _polylinePointCount;
>>>        [self _flushBuffers];
>>> +      if (count_save > 0) {
>>> +        // if color changes in the middle of polyline,
>>> +        // the last point of the path should be the
>>> +        // first point of the next path.
>>> +        _polylinePoints[0] = _polylinePoints[count_save - 1];
>>> +        _polylinePointCount = 1;
>>> +      }
>>>        _color = newColor;
>>>     }
>>>  }
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gnuplot-beta mailing list
>>> gnu...@li...
>>> Membership management via:
>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>>
>>