[XeTeX] how to write arabic in miktex

[el mouatakid Mohammed]

Garanti
sans virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Akira Kakuto]

Hi Jonathan,


What's unclear to me -- because I don't remember, if I ever
knew -- is quite why the driver wanted to treat FF(FF)
specially, and therefore what the implications of removing that
behavior might be.


In dvi.c, 0x was used as a sign that the font is not
colored, I don't know why. So opacity range was 0-254.
I simply introduced rgba_used to indicate the font is colored or not:


--- trunk/Build/source/texk/dvipdfm-x/dvi.c2020-05-26 00:59:53 UTC (rev 
55283)
+++ trunk/Build/source/texk/dvipdfm-x/dvi.c2020-05-26 13:45:50 UTC (rev 
55284)
@@ -147,6 +147,10 @@
  spt_t size;
  int   source; /* Source is either DVI or VF */
  uint32_t rgba_color;
+  uint8_t  rgba_used;
+/* Indicates that rgba_color is used or not.
+ * It enables full range of opacity: 0-255.
+ */
  int  xgs_id;  /* Transparency ExtGState */
  struct tt_longMetrics *hvmt;
  int   ascent;
@@ -180,6 +184,10 @@
  intused;
  intnative; /* boolean */
  uint32_t rgba_color;   /* only used for native fonts in XeTeX */
+  uint8_t  rgba_used;
+/* Indicates that rgba_color is used or not.
+ * It enables full range of opacity: 0-255.
+ */
  uint32_t face_index;
  intlayout_dir; /* 1 = vertical, 0 = horizontal */
  intextend;
@@ -554,6 +562,7 @@
  def_fonts[num_def_fonts].used= 0;
  def_fonts[num_def_fonts].native  = 0;
  def_fonts[num_def_fonts].rgba_color  = 0x;
+  def_fonts[num_def_fonts].rgba_used   = 0;
  def_fonts[num_def_fonts].face_index  = 0;
  def_fonts[num_def_fonts].layout_dir  = 0;
  def_fonts[num_def_fonts].extend  = 0x0001; /* 1.0 */
@@ -599,6 +608,7 @@

  def_fonts[num_def_fonts].layout_dir  = 0;
  def_fonts[num_def_fonts].rgba_color  = 0x;
+  def_fonts[num_def_fonts].rgba_used   = 0;
  def_fonts[num_def_fonts].extend  = 0x0001;
  def_fonts[num_def_fonts].slant   = 0;
  def_fonts[num_def_fonts].embolden= 0;
@@ -606,8 +616,10 @@
  if (flags & XDV_FLAG_VERTICAL)
def_fonts[num_def_fonts].layout_dir = 1;

-  if (flags & XDV_FLAG_COLORED)
-def_fonts[num_def_fonts].rgba_color  = get_unsigned_quad(dvi_file);
+  if (flags & XDV_FLAG_COLORED) {
+def_fonts[num_def_fonts].rgba_color = get_unsigned_quad(dvi_file);
+def_fonts[num_def_fonts].rgba_used = 1;
+  }

  if (flags & XDV_FLAG_EXTEND)
def_fonts[num_def_fonts].extend = get_signed_quad(dvi_file);
@@ -1492,8 +1504,9 @@
def_fonts[i].point_size);
}
loaded_fonts[font_id].rgba_color = def_fonts[i].rgba_color;
-/* Opacity: 0xff is fully opaque. */
-if ((loaded_fonts[font_id].rgba_color & 0xff) == 0xff) {
+loaded_fonts[font_id].rgba_used = def_fonts[i].rgba_used;
+/* if rgba_used == 0, not a colored font */
+if (loaded_fonts[font_id].rgba_used == 0) {
  loaded_fonts[font_id].xgs_id = -1;
} else {
  pdf_obj *xgs_dict;
@@ -1716,7 +1729,7 @@
yloc[i] = get_buffered_signed_quad();
  }

-  if (font->rgba_color != 0x) {
+  if (font->rgba_used == 1) {
pdf_color color;
pdf_color_rgbcolor(&color,
  (double)((unsigned char)(font->rgba_color >> 24) & 0xff) / 255,
@@ -1787,7 +1800,7 @@
   glyph_width, font->font_id, -1);
  }

-  if (font->rgba_color != 0x) {
+  if (font->rgba_used == 1) {
if (font->xgs_id >= 0) {
  graphics_mode(); 
  pdf_dev_grestore();


Thanks,
Akira

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Jonathan Kew]

On 26/05/2020 23:32, Ross Moore wrote:

Hi Phil,

On 26 May 2020, at 5:12 pm, Philip Taylor 
> wrote:


Ross Moore wrote:

I’m sorry, but this just doesn’t make any sense to me — but see 
further below.


No, the fourth couplet is TT, where T is "Transparency". 
Unfortunately , it is a misnomer, since 00 = completely transparent 
and FE is almost opaque, which is why I spoke of "opacity" rather 
than transparency.  Unfortunately FF is /not/ opaque when preceded by 
FF, because the driver treats FF [FF] specially.


As I said, it didn’t make sense to me.  :-)
Thanks for the clarification, and sorry for my added noise.


First it is important to realise that both flattening and conversion 
to CMKY will take place (the document is for digital printing).  When 
flattening takes place, RGB FF text will completely obscure the 
ground, and after conversion to CMYK there will then be no ink where 
the text occurs. Unfortunately as things are at the moment, there 
will be 1/256 bleed-through of the ground because the RGB white was 
not perfectly opaque.


"knockout", tho' interesting, should not be needed.  The example 
earlier sent shews that one can get very close to 100% white (and of 
course there are no white inks involved) but not to 100% and this is 
what I would like to achieve (and which should, IMHO, be 
achievable).  Were it not for the fact that the driver treats FF 
and  specially, there would be no problem at all in achieving 
my aim.


It looks like Akira has done what you wanted, so the exercise was a 
success. :-)




What's unclear to me -- because I don't remember, if I ever knew -- is 
quite why the driver wanted to treat FF(FF) specially, and therefore 
what the implications of removing that behavior might be. Does this 
mean, for example, that text will no longer respect colors set via other 
methods such as color \specials, because the font will be considered to 
have an inherent white color?


JK

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Ross Moore]

Hi Phil,

On 26 May 2020, at 5:12 pm, Philip Taylor 
mailto:p.tay...@hellenic-institute.uk>> wrote:

Ross Moore wrote:

I’m sorry, but this just doesn’t make any sense to me — but see further below.

No, the fourth couplet is TT, where T is "Transparency".  Unfortunately , it is 
a misnomer, since 00 = completely transparent and FE is almost opaque, which is 
why I spoke of "opacity" rather than transparency.  Unfortunately FF is not 
opaque when preceded by FF, because the driver treats FF [FF] specially.

As I said, it didn’t make sense to me.  :-)
Thanks for the clarification, and sorry for my added noise.


First it is important to realise that both flattening and conversion to CMKY 
will take place (the document is for digital printing).  When flattening takes 
place, RGB FF text will completely obscure the ground, and after conversion 
to CMYK there will then be no ink where the text occurs.  Unfortunately as 
things are at the moment, there will be 1/256 bleed-through of the ground 
because the RGB white was not perfectly opaque.

"knockout", tho' interesting, should not be needed.  The example earlier sent 
shews that one can get very close to 100% white (and of course there are no 
white inks involved) but not to 100% and this is what I would like to achieve 
(and which should, IMHO, be achievable).  Were it not for the fact that the 
driver treats FF and  specially, there would be no problem at all 
in achieving my aim.

It looks like Akira has done what you wanted, so the exercise was a success. :-)


** Phil.

Cheers.
Stay safe.

Ross


Dr Ross Moore
Department of Mathematics and Statistics
12 Wally’s Walk, Level 7, Room 734
Macquarie University, NSW 2109, Australia
T: +61 2 9850 8955  |  F: +61 2 9850 8114
M:+61 407 288 255  |  E: ross.mo...@mq.edu.au
http://www.maths.mq.edu.au
[cid:image001.png@01D030BE.D37A46F0]
CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

This message is intended for the addressee named and may
contain confidential information. If you are not the intended
recipient, please delete it and notify the sender. Views expressed
in this message are those of the individual sender, and are not
necessarily the views of Macquarie University. 

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Ulrike Fischer]

Am Tue, 26 May 2020 09:32:47 +0100 schrieb Philip Taylor:


> I imagine that this is simply an illustration of one of the many
> differences between German English and British English, but
> coming (as I do) from the wrong side of the great Euro-divide, I
> would find asking a volunteer to "properly support" something
> highly presumptuous — the furthest I would be willing to go in
> that direction would be to ask "if it might be possible to add
> full support for XXX at some point".  

Well this was a message for you and I would formulate a real bug
report differently (https://tug.org/pipermail/dvipdfmx/). But "ask"
implies for me normally the "if possible ..."


-- 
Ulrike Fischer 
http://www.troubleshooting-tex.de/

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Philip Taylor]

Ulrike Fischer wrote:



Well that is the problem when accepting "work-arounds" as
"solutions".

Instead of looking for the next workaround I would suggest to do
this time the right thing: Report the problem to the dvipdfmx
maintainer and ask them to properly support the colors FF and
.


I imagine that this is simply an illustration of one of the many differences between German English 
and British English, but coming (as I do) from the wrong side of the great Euro-divide, I would 
find asking a volunteer to "properly support" something highly presumptuous — the 
furthest I would be willing to go in that direction would be to ask "if it might be possible 
to add full support for XXX at some point".  Which of course I will do, once I can be sure who 
the current maintainer of [x]dvipdfmx is ...

/Philip Taylor/

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Ulrike Fischer]

Am Mon, 25 May 2020 12:00:42 +0100 schrieb Philip Taylor:

> Way back in 2015, I asked :
...

>> A work around is to set the color to FF00 (or any other
>> value for the alpha since xdvipdfmx does not support transparency
>> currently).
 
> and at the time, that appeared to solve my problem. However, it
> would appear that since then "xdvipdfmx" has been enhanced to
> support transparency, as a result of which Khaled's suggested
> FF00 no longer works 

Well that is the problem when accepting "work-arounds" as
"solutions".

> Could anyone tell me how, short of using \specials, I can achieve
> 100% white with 100% opacity (= 0% ink) in XeTeX ?

Instead of looking for the next workaround I would suggest to do
this time the right thing: Report the problem to the dvipdfmx
maintainer and ask them to properly support the colors FF and
. 


-- 
Ulrike Fischer 
http://www.troubleshooting-tex.de/

Re: [XeTeX] \font "":color=FFFFFF produces black, not white glyphs \font "":color=FFFFFF produces black, not white glyphs, re-visited

[Philip Taylor]

Ross Moore wrote:


On 25 May 2020, at 9:00 pm, Philip Taylor mailto:p.tay...@hellenic-institute.uk>> wrote:



[UNIV: Plain XeTeX] —

[i]t would appear that [] "xdvipdfmx" has been enhanced to support 
transparency, as a result of which Khaled's suggested FF00 no longer works (the text 
is invisible, see attached).  Could anyone tell me how, short of using \specials, I can 
achieve 100% white with 100% opacity (= 0% ink) in XeTeX ?


I’m sorry, but this just doesn’t make any sense to me — but see further below. 
Surely 100% opacity means that the blend between background and foreground is 
100% background, 0% foreground. Thus your text will be invisible, whatever 
colour has been specified; that this is white becomes irrelevant.


No, the fourth couplet is TT, where T is "Transparency". Unfortunately , it is a 
misnomer, since 00 = completely transparent and FE is almost opaque, which is why I spoke of 
"opacity" rather than transparency.  Unfortunately FF is /not/ opaque when preceded by 
FF, because the driver treats FF [FF] specially.


The only way to get 100% white, over a coloured background, would be with 100% 
ink, so 0% opacity.
Any other opacity level will allow some of the background colour to be mixed in.
At least that is how I understand what colour mixing is all about.


First it is important to realise that both flattening and conversion to CMKY 
will take place (the document is for digital printing). When flattening takes 
place, RGB FF text will completely obscure the ground, and after conversion 
to CMYK there will then be no ink where the text occurs.  Unfortunately as 
things are at the moment, there will be 1/256 bleed-through of the ground 
because the RGB white was not perfectly opaque.

"knockout", tho' interesting, should not be needed.  The example earlier sent 
shews that one can get very close to 100% white (and of course there are no white inks 
involved) but not to 100% and this is what I would like to achieve (and which should, 
IMHO, be achievable).  Were it not for the fact that the driver treats FF and 
 specially, there would be no problem at all in achieving my aim.

** Phil.