On 21/07/2019 12:45, Ikumi Keita wrote:
>> Ikumi Keita writes:
>> Hi AUCTeX developers,
>> I propose to commit the attached fix. Comments and suggestions are
>> welcome.
>
> I committed the proposed fix since no one raised objection. Please
> report any problem about it.
>
> I thank again
> Ikumi Keita writes:
> Hi AUCTeX developers,
> I propose to commit the attached fix. Comments and suggestions are
> welcome.
I committed the proposed fix since no one raised objection. Please
report any problem about it.
I thank again GS developers, especially Ken and Chris, for
Hi AUCTeX developers,
I propose to commit the attached fix. Comments and suggestions are
welcome.
> David Kastrup writes:
> Ok, that's puzzling. It really should have worked.
William Bader kindly provided me a revised code which works fine in
personal correspondances. However, I finally
Ikumi Keita writes:
>> David Kastrup writes:
The test would be something like
>>>
/GS_PDF_ProcSet where { pop [put old code here] } if
>>>
>>> Do you mean that the patch listed below should work?
>
>> No. The brackets in [put old code here] were part of the description,
>> not
> David Kastrup writes:
>>> The test would be something like
>>
>>> /GS_PDF_ProcSet where { pop [put old code here] } if
>>
>> Do you mean that the patch listed below should work?
> No. The brackets in [put old code here] were part of the description,
> not of the code.
Thanks, but the
Ikumi Keita writes:
>> David Kastrup writes:
>> I don't think that the drawback is necessary: in contrast to a working
>> DELAYBIND, it is easy to test for existence of the PDF dictionary at
>> runtime and use it if available.
>
>> The test would be something like
>
>> /GS_PDF_ProcSet where
> David Kastrup writes:
> I don't think that the drawback is necessary: in contrast to a working
> DELAYBIND, it is easy to test for existence of the PDF dictionary at
> runtime and use it if available.
> The test would be something like
> /GS_PDF_ProcSet where { pop [put old code here] }
Ikumi Keita writes:
>> Ikumi Keita writes:
>> I was just thinking to immigrate to the new code using DELAYBIND, and
>> announce the user to install patched gs-9.27 if in hurry. But it might
>> be a good idea to introduce a new user option to choose between
>> (1) No color transfer, "black
> Ikumi Keita writes:
> I was just thinking to immigrate to the new code using DELAYBIND, and
> announce the user to install patched gs-9.27 if in hurry. But it might
> be a good idea to introduce a new user option to choose between
> (1) No color transfer, "black on white" appearance
> (2)
> David Kastrup writes:
> Well, the principal problem is that Chris stated that one cannot check
> for the availability of a working DELAYBIND without enabling it, and
> enabling it will make the document blow up. So I guess we don't have
> much of a feasible option for now but to disable
Ikumi Keita writes:
> Hi David,
>
>> David Kastrup writes:
>> I'll probably pitch in from here (if nobody else does) and write code
>> that checks for the availability of any of these features and uses them.
>
> Do you have a plan to make a progress about this issue? If not, I'll
> make a
Hi David,
> David Kastrup writes:
> I'll probably pitch in from here (if nobody else does) and write code
> that checks for the availability of any of these features and uses them.
Do you have a plan to make a progress about this issue? If not, I'll
make a commit based on my previous
On 03/07/2019 08:36, David Kastrup wrote:
> Chris Liddell writes:
>
>> So, in essence, the idea is that you'll remove the stuff using
>> GS_PDF_ProcSet entirely. Add the option -dDELAYBIND to your gs command
>> line, include a suitable redefinition of initgraphics, then call
>> .bindnow, and
Ikumi Keita writes:
> Hi Chris,
>
>> Chris Liddell writes:
>> Right, sorry for the delay, as I said, that ended up being a much more
>> involved task than I'd anticipated!
>
> Thanks, the proposed fix works well on my side! The generated image
> turns its color as expected.
>
>> First and
Hi Chris,
> Chris Liddell writes:
> Right, sorry for the delay, as I said, that ended up being a much more
> involved task than I'd anticipated!
Thanks, the proposed fix works well on my side! The generated image
turns its color as expected.
> First and foremost (and apologies for this),
Chris Liddell writes:
> So, in essence, the idea is that you'll remove the stuff using
> GS_PDF_ProcSet entirely. Add the option -dDELAYBIND to your gs command
> line, include a suitable redefinition of initgraphics, then call
> .bindnow, and continue as before.
>
> The redefinition of
On 26/06/2019 18:01, Ikumi Keita wrote:
> Hi Chris,
>
>> Chris Liddell writes:
>> We think we have a way to achieve what you need, but it relies on the
>> DELAYBIND feature which, unfortunately, was inadvertently broken in 9.27
>> (possibly, in truth, earlier than that).
>
>> I thought this
Hi Chris,
> Chris Liddell writes:
> We think we have a way to achieve what you need, but it relies on the
> DELAYBIND feature which, unfortunately, was inadvertently broken in 9.27
> (possibly, in truth, earlier than that).
> I thought this (DELAYBIND) was going to be a fairly easy issue to
On 22/06/2019 15:15, Ken Sharp wrote:
> At 21:35 22/06/2019 +0900, Ikumi Keita wrote:
>
>
>> Thank you for your detailed explanation. I realize it is almost
>> hopeless to achive our original intent by just replacing the existing
>> Postscript code.
>
> Don't give up entirely yet, we are still
At 21:35 22/06/2019 +0900, Ikumi Keita wrote:
Thank you for your detailed explanation. I realize it is almost
hopeless to achive our original intent by just replacing the existing
Postscript code.
Don't give up entirely yet, we are still discussing this internally, but I
wanted to be
Hi Ken,
> Ken Sharp writes:
> At the moment, I cannot see any way to achieve this. What you are
> doing with the PDF interpreter is pretty much exactly the sort of
> thing we have spent time preventing. We really don't want people to be
> able to modify the PDF interpreter at all.
Thank you
Good Morning Keita,
At 00:06 21/06/2019 +0900, Ikumi Keita wrote:
> For example, if the PDF file uses black, and the Emacs current colour
> is (eg) green, then you want the PDF rendered as green.
That's right.
> So I'm going to assume this is some highly limited application of PDF
> and
Sorry, there were some inappropriate contents in my previous mail.
> Ikumi Keita writes:
> The files involved are attached with this message. Let me explain how
> these files are processed by preview-latex.
The attached PNG file was not generated during the mentioned process.
The gs
Hi Ken, thank you for your reply.
> Ken Sharp writes:
> Hi Keita,
> (or should that be Ikumi ? Please accept an apology if I'm wrong)
No problem, call me by whichever name you like. My given name is Keita
and the family name is Ikumi, but I don't care in English conversation.
> At 18:47
Hi Keita,
(or should that be Ikumi ? Please accept an apology if I'm wrong)
I asked this on our IRC channel, but it occurs to me that it may be outside
working hours for you now, so I'm following up by email.
At 18:47 20/06/2019 +0900, Ikumi Keita wrote:
In short, Ghostscript stops with
25 matches
Mail list logo
