A git patch would be welcome, but we at least need a signoff line for
the patch.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/518056
Title:
cedilla appears as accented c (ć instead of ç) when
Pushed as commit 121a1bad334459f66f78bfca6df53dc841cf97f8.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/518056
Title:
cedilla appears as accented c (ć instead of ç) when typing 'c
To manage
The desired behavior is that the dead_acute key followed by the c key
results in ccedilla, while keeping the original behavior for other letters.
It already does in the pt_BR.UTF-8 locale.
The compose file for pt_BR.UTF-8 includes the en_US.UTF-8 file and then
overrides some of the sequences,
Current kernels have KEY_MICMUTE==248, i. e. X.org should be
perfectly able to recognize this. Apparently this was done in
2011 already.
248 is the first linux kernel value which X cannot handle.
The mapping is +8, so 248 ⟹ 256, which does not fix in 8 bits.
(The first 8 are reserved – from
b == bugzilla-daemon bugzilla-dae...@freedesktop.org writes:
James, can you define the deficiencies in the spec linked from comment #9 so
that we can understand which parts of XFA still need to be documented?
For starters www.xfa.org does not exist. And xfa.org does not have an A
or
It looks like the xfa situation isn’t as dire as I’d been led to
understand.
OTOH, I’m not entirely certain that the licence text in the preface of
the pdf referenced in comment #9 is GPL-compatible. Or even DFSG-
compatible.
In any case (unless Albert things otherwise), it probably should not
Most of the information I have about xfa has come from the itext list.
An example of the type of info posted there:
http://support.itextpdf.com/node/134
If there is new info since 2011/12 I’d be interested to know.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Adobe would have to document XFA forms before this even could be
addressed.
The most up to date info I could find on that front is:
http://en.wikipedia.org/wiki/XFA#Standardization
As long as Adobe keeps XFA forms proprietary they are not potable and
livecycle and acroread are the only way
The renderings I get from evince (master, with poppler master and
cairo master), ghostscript (9.05 and master) and mupdf (master) all
match the png you posted as attachment #62423.
I looked at the document after running it though:
:; mupdfclean -d -a Abschlussarbeit.pdf Abschlussarbeit.pdfc
If we look Unicode charts, they also plan these association (written
under a character when there is one, for instance ⇱ is the home key)
I don't know of any system actually supporting this.
rxvt-unicode does, using ctrl-shift as the introducer.
It also supports C-S + code point entry and C-S
Sure, my patch just follows the license of the original code. So it's
in MIT/X11 license.
Cool. And to be clear, I only asked because of the license issue with
the first patch on this bug report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
A non-working PgUp is a common result of an impedance mismatch between
the input driver and the configured xkb keycodes.
You should confirm that both are evdev or that you have keyboard and a
suitable keycodes for that.
Xorg.0.log will show which input driver is used. xkbcomp :0 - |grep
Before the changes to the Compose files can be pushed, we need to
decide on what character to use for the apostrophe in the cʼh strings.
I spent some time before the holiday researching that.
The fdo bug reports and related posts in the list archives use U+2019
RIGHT SINGLE QUOTATION MARK.
But there is no one reason to switch keyboard layouts in back order
in first place, isn't it?
As someone who loads extra layouts just in case, I find the reverse
order switching to be invaluable.
I use lctrl+rctlr; it may be easier to deal with the reverse order
in such cases than with the
14 matches
Mail list logo
