Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-26 Thread Karl Berry 
so this is the other approach, with extracting of
problematic code to standalone files. I figured out that there is also
problem with some Russian accents. patch is attached.

Most excellent!  I installed the changes and updated tex4ht and TL.

K

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-26 Thread Michal Hoftich 
Karl,

> +require "luatexbase.mcb"
>
> By the way, I didn't see this file in the patch (or in TL).
> Not that it matters if we go the other route.

it is luatexbase/mcb.lua, it should be part of TL,

>
> +luatexbase.add_to_callback("open_read_file", patch_latin1,
>
> 1) For what it's worth, luainputenc.lua 
> ushttp://chat.stackexchange.com/login/global?returnurl=http%3a%2f%2fchat.stackexchange.com%2frooms%2f41%2ftex-latex-and-friendses
>  process_input_buffer instead
> of open_read_file.  I don't know if performance is better.
>

but we can't see the filename from `process_input_buffer`
> 2) Isn't the whole issue about Latin 2, not Latin 1?

you are right! so this is the other approach, with extracting of
problematic code to standalone files. I figured out that there is also
problem with some Russian accents. patch is attached.

Michal
>
> K
Index: tex4ht-html4.tex
===
--- tex4ht-html4.tex	(revision 133)
+++ tex4ht-html4.tex	(working copy)
@@ -10,7 +10,7 @@
 % See tex4ht-cpright.tex for license text.
 
 \ifx \HTML\UnDef
-   \def\HTML{html4,html4-math,html4-uni} 
+   \def\HTML{html4,html4-math,html4-uni,html4-l2-url,html4-russian-accents} 
\def\CONFIG{\jobname}
\def\MAKETITLE{\author{Eitan M. Gurari}}
\def\next{\input mktex4ht.4ht  \endinput}
@@ -13075,6 +13075,10 @@
 
 
 \<<<
+\input{html4-russian-accents.4ht}
+>>>
+
+\<<<
 \Configure{accent}\"\ddot{|å{00EB}%
{\@use@text@encoding \@curr@enc A}{00C4}%
{\@use@text@encoding \@curr@enc E}{00CB}%
@@ -18097,6 +18101,10 @@
 
 
 \<<<
+\input{html4-l2-url.4ht}
+>>>
+
+\<<<
 \Configure{url-encoder}
   {%}{%25}
   {&}{%26}

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-23 Thread Karl Berry 
+require "luatexbase.mcb"

By the way, I didn't see this file in the patch (or in TL).
Not that it matters if we go the other route.

+luatexbase.add_to_callback("open_read_file", patch_latin1, 

1) For what it's worth, luainputenc.lua uses process_input_buffer instead
of open_read_file.  I don't know if performance is better.

2) Isn't the whole issue about Latin 2, not Latin 1?

K

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-23 Thread Karl Berry 
compilation time is about 50% longer on sample document, 

Too bad.  

conditional including of latin1 file, 

Sounds worth looking into ...

Thanks,
K

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-23 Thread Michal Hoftich 
I've made patch for tex4ht-sty.tex and tex4ht-html4.tex for loading
the callback under LuaTeX and modified the callback to be little bit
more universal.

I added line `% !4ht encoding = latin1` as first line of html4.4ht and
check for that line in the callback. Overhead isn't as small as I
expected, compilation time is about 50% longer on sample document, so
maybe the other solution, conditional including of latin1 file, might
be better.

Michal

2015-01-23 9:41 GMT+01:00 Michal Hoftich :
>>
>> Yeah, that's probably what's going on.  I'll work on it again
>> when I have a chance.
>>
>
> but this happened to me last summer and then things started to work
> correctly, honestly, I have no idea what did I do what fix it.
>
>> sometimes people try to install it, I am afraid
>>
>> Really?  It never occurred to me that anyone would be crazy enough to
>> get that obviously-ancient tex4ht from CTAN and try to do anything with
>> it.  Using Eitan's packages was never the easiest thing to do ...
>>
>
> I think I've read some blog posts or forum messages about difficulty
> of tex4ht installation, but can't find anything now.
>
> Michal
>
>
>> Thanks,
>> K
Index: tex4ht-sty.tex
===
--- tex4ht-sty.tex  (revision 133)
+++ tex4ht-sty.tex  (working copy)
@@ -1213,7 +1213,21 @@
\def\:temp{#1}\ifx \:temp\empty \else \expand:after{#2}\fi }
 >>>
 
+Fix for html4.4ht and LuaTeX. html4.4ht contains some characters in latin1 
+encoding. this causes LuaTeX compilation errors. because of backward 
+compatibility we want to keep these configurations, so we use
+LuaTeX's callbacks to fix that on the fly.
 
+\<<<
+\expandafter\ifx\csname luatexversion\endcsname\relax
+\else
+\directlua{%
+require "luatexbase.mcb"
+local patch_latin1 = require "inputcallback"
+luatexbase.add_to_callback("open_read_file", patch_latin1, "Convert html4.4ht 
to utf8")
+}
+\fi
+>>>
 \Chapter{Configurations}
 
 
Index: tex4ht-html4.tex
===
--- tex4ht-html4.tex(revision 133)
+++ tex4ht-html4.tex(working copy)
@@ -66,6 +66,7 @@
 
 
 \<<<
+% !4ht encoding = latin1
 % html4.4ht (|version), generated from |jobname.tex
 % Copyright (C) 2009-2010 TeX Users Group
 % Copyright (C) |CopyYear.1997. Eitan M. Gurari


pokus.tex
Description: TeX document
-- file html4.4ht is saved in latin1 encoding, which causes
-- troubles with unicode engines. I don't know whether it is safe
-- to convert this file to utf8, so we use `open_input_file` callback
-- for the conversion on the fly
local latin1_to_utf8 = require "l4latin1"

local function get_enc(contents)
	local contents = contents or ""
	-- local line = contents:match("(.-)[\n\r]") or ""
	--local line = contents:sub(1,24)--match("([^\n]+)") or ""
	--return line:match("4ht encoding = ([a-z0-9%-]-)")
	return contents:match("%% !4ht encoding = [a-z0-9%-]-")
	-- return line == "% !4ht encoding = latin1"
end

local function readFile(fn)
	local file = assert(io.open(fn, "r"))
	local contents = file:read("*a")
	file:close()
	-- this is not really flexible solution :)
	if fn:match "4ht$" then
		local enc = get_enc(contents)
		if enc then
			contents = contents:gsub("([\127-\255])", function(c)
local x = string.byte(c)
return latin1_to_utf8[x]
			end)
		end
	end
	return contents
end
local function processInputFile(contents)
	-- Process the file: Return each line
	if not contents then
		print ("nil content")
		return nil
	end
	for line in contents:gmatch("(.-)[\n\r]") do
		coroutine.yield(line)
	end
	while true do
		coroutine.yield(nil)
	end
end
-- return callabck function
return function(fileName)
	local contents = readFile(fileName)
	return {
		reader = coroutine.wrap(function()
			processInputFile(contents)
		end)
	}
end
-- this file is a copy of context's `regi-8859-1.lua`
-- just for the case when context isn't installed
-- it is used for latin1 to utf8 conversion
if not modules then modules = { } end modules ['regi-8859-1'] = {
version = 1.001,
comment = "companion to regi-ini.mkiv",
author = "Hans Hagen, PRAGMA-ADE, Hasselt NL",
copyright = "PRAGMA ADE / ConTeXt Development Team",
license = "see context related readme files"
}
return { [0] =
0x, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000A, 0x000B, 0x000C, 0x000D, 0x000E, 0x000F,
0x0010, 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, 0x0016, 0x0017, 0x0018, 0x0019, 0x001A, 0x001B, 0x001C, 0x001D, 0x001E, 0x001F,
0x0020, 0x0021, 0x0022, 0x0023, 0x0024, 0x0025, 0x0026, 0x0027, 0x0028, 0x0029, 0x002A, 0x002B, 0x002C, 0x002D, 0x002E, 0x002F,
0x0030, 0x0031, 0x0032, 0x0033, 0x0034, 0x0035, 0x0036, 0x0037, 0x0038, 0x0039, 0x003A, 0x003B, 0x003C, 0x003D, 0x003E, 0x003F,
0x0040, 0x0041, 0x0042, 0x0043, 0x0044, 0x0045, 0x0046, 0x0047, 0x0048, 0x0049, 0x004A, 0x004B, 0x004C, 0x004D, 0x004E, 0x004F,
0x0050, 0x0051, 0x0052, 0x0053, 0x0054, 0x0055, 0x0056, 0x0057, 0x0058, 0x0059, 0x005A, 0x005B, 0x005

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-23 Thread Michal Hoftich 
>
> Yeah, that's probably what's going on.  I'll work on it again
> when I have a chance.
>

but this happened to me last summer and then things started to work
correctly, honestly, I have no idea what did I do what fix it.

> sometimes people try to install it, I am afraid
>
> Really?  It never occurred to me that anyone would be crazy enough to
> get that obviously-ancient tex4ht from CTAN and try to do anything with
> it.  Using Eitan's packages was never the easiest thing to do ...
>

I think I've read some blog posts or forum messages about difficulty
of tex4ht installation, but can't find anything now.

Michal


> Thanks,
> K

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-23 Thread Michal Hoftich 
2015-01-23 1:42 GMT+01:00 Karl Berry :
> https://github.com/michal-h21/lua4ht/blob/math/l4patchlatin1.lua
>
> Cool, though it seems to me something simpler should be possible -- to
> write a declaration for luatex at the beginning of the file that "this
> file is in encoding xxx".  (Of course that won't help when it contains
> both Latin1 and Latin2, but that's a different issue.)
>

maybe there could be something like

% !4ht encoding = latin1

as first line of such files. if we had to read just first line of each
file from Lua callback, it shouldn't be big overhead.

we can check for LuaTeX and install callback in tex4ht.sty, which will
ensure that each .4ht file is processed.

> > Another idea is to move that chunk of input to a separate file, which
> > only gets read when that option is in effect.
> that might be perhaps the best solution?
>
> Anything that works is fine with me, of course.  I thought ^^ would be
> the least invasive thing to try.

I've tried to replace some characters with ^^ notation, but the
conversion haven't worked.

Michal

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Karl Berry 
Of course.  We have several of Eitan's releases, including that last
one, archived permanently on tug.org
(ftp://tug.org/mirror/www.cse.ohio-state.edu/~gurari/TeX4ht/*.zip at the
moment), regardless of anything else that happens.

Karl

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread William F Hammond 
On Thu, Jan 22, 2015 at 4:54 PM, Karl Berry  wrote:

> Moving to /obsolete is usual for CTAN, though I suppose I could ask them
> to delete it completely.
>

One never knows when one might want to look back.  Therefore, if any change
is to be made at CTAN, I would suggest archiving Eitan's last version
rather than deleting it, possibly with a note that it's for reference but
not for current use.

Just my €.02

  -- Bill

-- 
William F Hammond
Email: gel...@gmail.com
https://www.facebook.com/william.f.hammond
http://www.albany.edu/~hammond/

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Karl Berry 
Oh, I don't get such huge diff, see the attachment.

Hmm.

caused compilation errors on tex4ht-html4.tex

Yeah, that's probably what's going on.  I'll work on it again
when I have a chance.

it is: http://www.ctan.org/pkg/tex4ht

Oops, I forgot that we moved it to obsolete.

but it seems to be really old version with "obsolete" message, but

It's the last release Eitan made.  We've never managed to make another.

Moving to /obsolete is usual for CTAN, though I suppose I could ask them
to delete it completely.

sometimes people try to install it, I am afraid

Really?  It never occurred to me that anyone would be crazy enough to
get that obviously-ancient tex4ht from CTAN and try to do anything with
it.  Using Eitan's packages was never the easiest thing to do ...

Thanks,
K

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Karl Berry 
https://github.com/michal-h21/lua4ht/blob/math/l4patchlatin1.lua

Cool, though it seems to me something simpler should be possible -- to
write a declaration for luatex at the beginning of the file that "this
file is in encoding xxx".  (Of course that won't help when it contains
both Latin1 and Latin2, but that's a different issue.)

> Another idea is to move that chunk of input to a separate file, which
> only gets read when that option is in effect.
that might be perhaps the best solution?

Anything that works is fine with me, of course.  I thought ^^ would be
the least invasive thing to try.

K

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Michal Hoftich 
2015-01-22 19:21 GMT+01:00 Karl Berry :
> characters which should be replaced with entites in \url commands.
>
> I think that's right.
>
> this declaration is used only when `url-il2-pl` command line option is
> used. not all special characters are declared. now, the problem is
> with lualatex, as it is unicode engine, it reports invalid utf-8
> sequence even if it doesn't use url-encoders at all.
>
> as it is unlikely that anybody uses still latin2 encoding and special
> characters in urls at the same time, and given that list of these
> escaped special characters isn't comprehensive anyway, maybe we should
> take that away? because it causes compile errors every time tex4ht is
> used with lualatex.
>
> Oh.  Clearly we need to solve it somehow, but I don't much like the idea
> of getting rid of functionality, even something as obscure and probably
> little-used as this.  Plenty of people still use Latin N encodings, and
> there is an active TeX community in Poland -- I surmise that's who asked
> for that option in the first place.
>

OK. clearly someone needed it, as it is only configuration provided
for any input encoding for url-encoder.

> LuaTeX can certainly read files in any encoding, including plain bytes,
> not just UTF-8.  I'm afraid I don't have any recipes at hand, though
> it seems like it should be doable.
>

it is possible to use luatex's callback to convert read file to utf8
on the fly. I did that when I tried to use callbacks to write html
directly from LuaLaTeX:

https://github.com/michal-h21/lua4ht/blob/math/l4patchlatin1.lua


> But a simpler idea comes to mind: how about replacing the problematic
> characters with TeX's ^^xx notation?  I'm not sure if the conversions
> will happen at the right time, given that \url is changing everything
> around anyway, but we can wait and see if anyone notices.  At least it
> would go through at the input level and is one step beyond just deleting it.
>
> Another idea is to move that chunk of input to a separate file, which
> only gets read when that option is in effect.

that might be perhaps the best solution?

thanks,
Michal

>
> Thanks,
> Karl

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Michal Hoftich 
Hi Karl,

2015-01-22 19:09 GMT+01:00 Karl Berry :
> Hi Michal,
>
> don't you mean CTAN version?
>
> No, I meant what I said, though I wasn't clear.  See following:
>

ah, OK.

> I though TL got updates.
>
> Yes, I have been installing updated *.4ht files in TL as we make fixes
> (ever since Eitan).
>
> However, in the particular case of html4.4ht, there are significant
> differences between what is in TL and what is generated from our current
> source (you can do the diff as well as I can, but attached anyway).
> It seems a whole chunk of code is missing.
>
> I'm not sure at what point the differences started happening, but I kind
> of suspect with TL14 or maybe TL13.  I did do a few previous updates to
> html4.4ht over the past few years, so I suspect they were ok until then.
>

Oh, I don't get such huge diff, see the attachment.

I also checked diffs on tex4ht-html4.tex in tex4ht svn web frontend
and there weren't such big changes.

http://svn.gnu.org.ua/viewvc/tex4ht/trunk/lit/tex4ht-html4.tex?r1=133&view=log

but now I remember that in the past (I think last summer) something
caused compilation errors on tex4ht-html4.tex and more than 100 errors
happened, so the dvi file wasn't complete. but as compilation of other
files continued, it was easy to overlook that. I can't reproduce that
now, as compilation works fine.



> I think it should be safe to update CTAN as well,

>
> tex4ht has never been on CTAN.  Eitan never uploaded it there or made it
> feasible for them to mirror.  Maybe one day.

it is: http://www.ctan.org/pkg/tex4ht
but it seems to be really old version with "obsolete" message, but
sometimes people try to install it, I am afraid

>
> so Miktex can be updated as well.
>
> Christian (Schenk, aka MiKTeX) can get the updated *.4ht files from TL.
> Whether he actually does for tex4ht, I don't know, but I have the
> impression that he does get at least some stuff from TL.
>

thanks,

Michal

> I'll answer separately about latin2.
>
> Thanks,
> Karl
>
1c1
< % html4.4ht (2015-01-22-20:26), generated from tex4ht-html4.tex
---
> % html4.4ht (2013-08-07-08:10), generated from tex4ht-html4.tex
19,20c19
< % version identification would be appreciated.
< \immediate\write-1{version 2015-01-22-20:26}
---
> % version identification would be appreciated.\immediate\write-1{version 
> 2013-08-07-08:10}
3224c3223
< \def\:tempc{\special{t4ht@+\string&{35}xAE{59}}x}
---
> \def\:tempc{\special{t4ht@+\string&{35}xAE{59}}x;}
5912c5911
< .subsectionToc \string~ .subsubsectionToc
---
> .subsectionToc \string~ .subsubsectionToc,
28844d28842
< 
29634d29631
< 
30233d30229
< 
36143d36138
< 
36255a36251
> 
36355d36350
< 
36448a36444
> 
36504d36499
< 
36514a36510
> 
36576d36571
< 
36587a36583
> 
36861d36856
< 
36921a36917
> 
37000a36997
> 
37469d37465
< 
37501a37498
> 
37544d37540
< 
37750a37747
> 
37853d37849
< 
37878a37875
> 
38035a38033
> 
38066d38063
< 
38076a38074
> 
38107d38104
< 
38117a38115
> 
38148d38145
< 
38158a38156
> 
38401d38398
< 
38590a38588
> 
38832d38829
< 
38842a38840
> 
38873d38870
< 
38883a38881
> 
39093d39090
< 
39103a39101
> 
39134d39131
< 
39144a39142
> 
39175d39172
< 
39185a39183
> 
39403d39400
<

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Karl Berry 
characters which should be replaced with entites in \url commands.

I think that's right.

this declaration is used only when `url-il2-pl` command line option is
used. not all special characters are declared. now, the problem is
with lualatex, as it is unicode engine, it reports invalid utf-8
sequence even if it doesn't use url-encoders at all.

as it is unlikely that anybody uses still latin2 encoding and special
characters in urls at the same time, and given that list of these
escaped special characters isn't comprehensive anyway, maybe we should
take that away? because it causes compile errors every time tex4ht is
used with lualatex.

Oh.  Clearly we need to solve it somehow, but I don't much like the idea
of getting rid of functionality, even something as obscure and probably
little-used as this.  Plenty of people still use Latin N encodings, and
there is an active TeX community in Poland -- I surmise that's who asked
for that option in the first place.

LuaTeX can certainly read files in any encoding, including plain bytes,
not just UTF-8.  I'm afraid I don't have any recipes at hand, though
it seems like it should be doable.

But a simpler idea comes to mind: how about replacing the problematic
characters with TeX's ^^xx notation?  I'm not sure if the conversions
will happen at the right time, given that \url is changing everything
around anyway, but we can wait and see if anyone notices.  At least it
would go through at the input level and is one step beyond just deleting it.

Another idea is to move that chunk of input to a separate file, which
only gets read when that option is in effect.

Thanks,
Karl

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-22 Thread Karl Berry 
Hi Michal,

don't you mean CTAN version? 

No, I meant what I said, though I wasn't clear.  See following:

I though TL got updates.

Yes, I have been installing updated *.4ht files in TL as we make fixes
(ever since Eitan).

However, in the particular case of html4.4ht, there are significant
differences between what is in TL and what is generated from our current
source (you can do the diff as well as I can, but attached anyway).
It seems a whole chunk of code is missing.

I'm not sure at what point the differences started happening, but I kind
of suspect with TL14 or maybe TL13.  I did do a few previous updates to
html4.4ht over the past few years, so I suspect they were ok until then.

I think it should be safe to update CTAN as well, 

tex4ht has never been on CTAN.  Eitan never uploaded it there or made it
feasible for them to mirror.  Maybe one day.

so Miktex can be updated as well.

Christian (Schenk, aka MiKTeX) can get the updated *.4ht files from TL.
Whether he actually does for tex4ht, I don't know, but I have the
impression that he does get at least some stuff from TL.

I'll answer separately about latin2.

Thanks,
Karl



html4.dif.gz
Description: Binary data

Re: [tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-20 Thread Michal Hoftich 
> thanks as always, michal. i installed the changes and also updated TeX Live.
>

thanks, Karl

> doing this reminded me of an issue i discovered long ago and forgot to get
> back to: the generated files from our current tex4ht-html4.tex differ
> significantly from what's being distributed in TL (i.e., Eitan's last
> version).  If you uncomment it in the Makefile, run it, and diff it, you will
> see.  maybe you could look into that so we could get back in sync?  (I'm
> heading out the door and will be offline for a couple days, or I'd look at
> now; I hope it isn't anything deep.)
>

don't you mean CTAN version? I though TL got updates. I think it
should be safe to update CTAN as well, so Miktex can be updated as
well.

one question regarding tex4ht-html4.tex, this file does contain some
latin2 encoded characters, in particular it is configuration for
url-encoder. if I understand it correctly, this should declare
characters which should be replaced with entites in \url commands.
this declaration is used only when `url-il2-pl` command line option is
used. not all special characters are declared. now, the problem is
with lualatex, as it is unicode engine, it reports invalid utf-8
sequence even if it doesn't use url-encoders at all.

as it is unlikely that anybody uses still latin2 encoding and special
characters in urls at the same time, and given that list of these
escaped special characters isn't comprehensive anyway, maybe we should
take that away? because it causes compile errors every time tex4ht is
used with lualatex.

regards,
Michal
> Thanks,
> K
>

[tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-20 Thread Karl Berry 
Update of bug #242 (project tex4ht):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
 Summary: Spurious semicolon produced by \textregistered
command => Spurious semicolon produced by textregistered command

___

Follow-up Comment #1:

thanks as always, michal. i installed the changes and also updated TeX Live.

doing this reminded me of an issue i discovered long ago and forgot to get
back to: the generated files from our current tex4ht-html4.tex differ
significantly from what's being distributed in TL (i.e., Eitan's last
version).  If you uncomment it in the Makefile, run it, and diff it, you will
see.  maybe you could look into that so we could get back in sync?  (I'm
heading out the door and will be offline for a couple days, or I'd look at
now; I hope it isn't anything deep.)

Thanks,
K


___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/

[tex4ht] [bug #242] Spurious semicolon produced by \textregistered command

2015-01-19 Thread Michal Hoftich 
URL:
  

 Summary: Spurious semicolon produced by \textregistered
command
 Project: tex4ht
Submitted by: michal_h21
Submitted on: Mon 19 Jan 2015 10:28:13 EET
Category: None
Priority: 5 - Normal
Severity: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

As reported on TeX.sx:

http://tex.stackexchange.com/questions/223804/tex4ht-textregistered-and-an-unwanted-semicolon

\textregistered command produces `®;` text, instead of just `®`. This
spurious semicolon is introduced in patches for \textregistered in tex4ht
sources.

Patch for tex4ht-html4.tex and tex4ht-unicode.tex is attached



___

File Attachments:


---
Date: Mon 19 Jan 2015 10:28:13 EET  Name: textregistered.patch  Size: 1kB  
By: michal_h21



___

Reply to this item at:

  

___
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/