!NuxCISwYQJuyWwNsEI:matrix.org

PGF/TikZ

56 Members
https://github.com/pgf-tikz11 Servers

Load older messages


SenderMessageTime
8 Oct 2021
@hmenke:matrix.orghmenke *
--- test-rgb.pdf	2021-10-08 16:43:12.219667000 +0200
+++ test-cmyk.pdf	2021-10-08 16:39:27.077766000 +0200
@@ -17,7 +17,7 @@
 endobj
 5 0 obj
 <<
-/Shading << /Sh << /ShadingType 2 /ColorSpace /DeviceRGB /Domain [0 1] /Coords [0 0.0 0 4.2895] /Function  << /FunctionType 2 /Domain [0 1] /C0 [0 0 0] /C1 [0 0 0] /N 1 >>  /Extend [false false] >> >>
+/Shading << /Sh << /ShadingType 2 /ColorSpace /DeviceCMYK /Domain [0 1] /Coords [0 0.0 0 4.2895] /Function  << /FunctionType 2 /Domain [0 1] /C0 [0 0 0 1] /C1 [0 0 0 1] /N 1 >>  /Extend [false false] >> >>
 /ProcSet [ /PDF ]
 >>
 endobj
@@ -48,11 +48,11 @@
 /FormType 1
 /Matrix [1 0 0 1 0 0]
 /Resources 9 0 R
-/Length 79        
+/Length 81        
 >>
 stream
 q 
-1 1 1 rg 1 1 1 RG
+0 0 0 0 k 0 0 0 0 K
 q
 1 0 0 1 0 0 cm
 /Fm1 Do
@@ -78,20 +78,20 @@
 endobj
 12 0 obj
 <<
-/Length 612       
+/Length 631       
 >>
 stream
-0 0 0 rg 0 0 0 RG
+0 0 0 1 k 0 0 0 1 K
 0 g 0 G
-0 0 0 rg 0 0 0 RG
-0 0 0 rg 0 0 0 RG
-0 0 0 rg 0 0 0 RG
+0 0 0 1 k 0 0 0 1 K
+0 0 0 1 k 0 0 0 1 K
+0 0 0 1 k 0 0 0 1 K
 1 0 0 1 3.387 7.677 cm
 q 
-0 0 0 RG 
-0 0 0 rg 
+0 0 0 1 K 
+0 0 0 1 k 
 0.3985 w 
-1 0 0 rg 
+0 1 1 0 k 
 2.0 0.0 0.0 2.0 -85.04044 -4.2895 cm 
 /pgfsmask7 gs
 0.5 0.0 0.0 0.5 42.52022 2.14474 cm 
@@ -115,10 +115,10 @@
 1 0 0 1 -3.387 -7.478 cm
 []0 d 0 J 0.398 w 0 0 m 91.814 0 l S
 Q
-0 0 0 rg 0 0 0 RG
-0 0 0 rg 0 0 0 RG
-0 0 0 rg 0 0 0 RG
-0 0 0 rg 0 0 0 RG
+0 0 0 1 k 0 0 0 1 K
+0 0 0 1 k 0 0 0 1 K
+0 0 0 1 k 0 0 0 1 K
+0 0 0 1 k 0 0 0 1 K
 
 endstream
 endobj
@@ -169,26 +169,26 @@
 xref
 0 16
 0000000000 65535 f 
-0000001967 00000 n 
-0000002042 00000 n 
-0000002062 00000 n 
+0000001993 00000 n 
+0000002068 00000 n 
+0000002088 00000 n 
 0000000015 00000 n 
 0000000186 00000 n 
-0000000665 00000 n 
-0000000426 00000 n 
-0000001025 00000 n 
-0000000908 00000 n 
-0000001875 00000 n 
-0000001761 00000 n 
-0000001090 00000 n 
-0000002115 00000 n 
-0000002174 00000 n 
-0000002225 00000 n 
+0000000670 00000 n 
+0000000431 00000 n 
+0000001032 00000 n 
+0000000915 00000 n 
+0000001901 00000 n 
+0000001787 00000 n 
+0000001097 00000 n 
+0000002141 00000 n 
+0000002200 00000 n 
+0000002251 00000 n 
 trailer
 << /Size 16
 /Root 14 0 R
 /Info 15 0 R
  >>
 startxref
-2297
+2323
 %%EOF
14:43:37
@samcarter:matrix.orgsamcarter
In reply to @hmenke:matrix.org
I compiled the PDF with both CMYK and RGB and took the diff, but there is nothing suspicious.
Thanks for taking a look!
14:53:16
@samcarter:matrix.orgsamcarterthe cmyk shading problem seems to first occur in TL2019, with TL2018 from overleaf it seems to work fine14:57:24
@samcarter:matrix.orgsamcarter... seems related to the new shadings colour space thingy from 65da52fd74426af68a42dcf5bffacf0aec209a1a15:07:01
@samcarter:matrix.orgsamcarter... guess I'll create an issue about this15:10:50
@hmenke:matrix.orghmenkeWell, before that all shadings were just RGB, which is a different problem.15:16:50
@samcarter:matrix.orgsamcarterThe easiest solution would just to abolish cyan - for the other colours one does not really notice a difference between the models :)15:21:09
@u-fischer:matrix.orgUlrike Fischer samcarter: what is the problem with cmyk? It looks ok to me. 16:10:16
11 Oct 2021
@hmenke:matrix.orghmenke muzimuzhi: What do you think about requiring Conventional Commits for PGF? 10:12:30
@hmenke:matrix.orghmenke josephwright: I've experimented with flattening the doc tree: https://github.com/hmenke/pgf/commit/4e30e38136b9e6acda47975525596c004fade355 17:59:53
@hmenke:matrix.orghmenkeIt works okay but there are some problems with usability.18:00:11
@hmenke:matrix.orghmenkeThe aux files are not reusable between the different engines.18:00:37
@hmenke:matrix.orghmenkeSo after compiling for, e.g. LuaTeX all aux files have to be deleted before being able to compile with. e.g. tex4ht.18:01:14
@hmenke:matrix.orghmenkeThere error messages that this causes are also not exactly useful.18:01:36
@hmenke:matrix.orghmenke* The error messages that this causes are also not exactly useful.19:18:56
@josephwright:matrix.orgjosephwright
In reply to @hmenke:matrix.org
The aux files are not reusable between the different engines.
Well yes, that would be expected: l3build expects a single engine to be used for docs, or for things to be cleaned up if you make major changes
21:36:26
@josephwright:matrix.orgjosephwright
In reply to @hmenke:matrix.org
The error messages that this causes are also not exactly useful.
It's aimed at automation: stuff that's out-and-out broken tends to require manual work first
21:36:51
@josephwright:matrix.orgjosephwright
In reply to @hmenke:matrix.org
josephwright: I've experimented with flattening the doc tree: https://github.com/hmenke/pgf/commit/4e30e38136b9e6acda47975525596c004fade355
I've got some other stuff to look at for a few days: I'll try to get back to this after that (I want to read Marcel Krüger's suggestion)
21:37:23
12 Oct 2021
@muzzi:matrix.orgmuzimuzhi
In reply to @hmenke:matrix.org
muzimuzhi: What do you think about requiring Conventional Commits for PGF?
That's good and will help train contributors, including me, into real developers. Though I think insufficient contributions is another problem that PGF encounters.
04:47:02
@muzzi:matrix.orgmuzimuzhi
In reply to @hmenke:matrix.org
There is actually a related thing that I wanted to discuss with the L3 team at some point (probably at a future TUG/Dante/etc meeting): More and more expl3 constructs are infiltrating the LaTeX kernel which is a good thing, since they bring new robust features, but the big downside is that \tracingall becomes more and more useless because expl3 produces lots of log spam. For most users this is a non-issue but developers will have a hard time tracking down bugs. We don't have to (and probably shouldn't) discuss this now; just something to keep in mind.

Maybe https://ctan.org/pkg/unravel can help, but some further development based on it is needed.

I've been using unravel when debugging or understanding the source code for sometime and it does a great work.

The cons are, an extra level of abstraction, inactive maintainers (@PhelypeOleinik may already get some familiarity about the code base, according to this issue comment), and the difficulties of debugging unravel.

04:59:00
@muzzi:matrix.orgmuzimuzhi
In reply to @hmenke:matrix.org
muzimuzhi: What do you think about requiring Conventional Commits for PGF?
* That's good and will help train contributors, including me, into real (or better) developers. Though I think insufficient contributions is another problem that PGF encounters.
09:45:19
@josephwright:matrix.orgjosephwright
In reply to @muzzi:matrix.org

Maybe https://ctan.org/pkg/unravel can help, but some further development based on it is needed.

I've been using unravel when debugging or understanding the source code for sometime and it does a great work.

The cons are, an extra level of abstraction, inactive maintainers (@PhelypeOleinik may already get some familiarity about the code base, according to this issue comment), and the difficulties of debugging unravel.

Both Phelype Oleinik and I know something about the code: I guess we should fix the issues :)
09:45:58
@hmenke:matrix.orghmenke muzimuzhi: unravel is a very impressive effort but unfortunately it is very slow and only helps with expansion. For instances where I have to find a spurious space I cannot get around \tracingall. It would be nice if there was some engine feature to filter the logs. 10:42:04
@muzzi:matrix.orgmuzimuzhiYes, it's not a silver bullet 😮‍💨10:43:44
@hmenke:matrix.orghmenke Or something to exempt certain macros from tracing altogether and only resume tracing when the expansion of that has finished (looking at you \pgfmathparse). 10:44:06
@hmenke:matrix.orghmenke

Although, this might actually do the trick for \pgfmathparse

--- a/tex/generic/pgf/math/pgfmathparser.code.tex
+++ b/tex/generic/pgf/math/pgfmathparser.code.tex
@@ -19,6 +19,7 @@
 
 \def\pgfmathparse{%
   \begingroup
+    \tracingnone
     \pgfmath@catcodes
     \pgfmath@quickparsefalse
     % Test for the fpu library
10:46:17
@hmenke:matrix.orghmenke This of course does not work for stuff that has to be expandable like \pgfutil@ifnextchar or so. Most of the time I don't care how it figures out which branch to take but only which branch is taken. 10:50:01
@muzzi:matrix.orgmuzimuzhi
In reply to @hmenke:matrix.org
Or something to exempt certain macros from tracing altogether and only resume tracing when the expansion of that has finished (looking at you \pgfmathparse).
Deciding whether a macro has "finished" is non-trivial i guess. The info of where a token comes from is required. Expansion of a macro? \aftergroup? Read from input file? ...
10:52:29
@hmenke:matrix.orghmenke I don't think it's non-trivial. When TeX sees \pgfutil@ifnextchar it reads #1#2#3 from the input and starts expansion. As soon as TeX reads the next token from the input it means that \pgfutil@ifnextchar has finished. 10:54:03
@hmenke:matrix.orghmenkeThat's something that should be quite easy to introspect on the engine level.10:54:54

Show newer messages


Back to Room ListRoom Version: 6