N-Trig Tablet Not Recognized

New Here ,
Jan 29, 2009 Jan 29, 2009

Copy link to clipboard

Copied

A few other HP and Dell tablet PC users and I have noticed that photoshop does not recognize the pressure sensitivity of the N-trig tablets. I bought this laptop thinking that it was Wacom because I knew it was pressure sensitive (which it is on a couple other programs) so I was a little surprised when I found out that there was more than one type of digitizer pen.

Is there a work around, patch or some other way to get Photoshop and Elements to recognize it?

I contacted N-Trig already and they basically said it's the software's issue.

Views

48.0K

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
replies 106 Replies 106
Participant ,
Jan 29, 2009 Jan 29, 2009

Copy link to clipboard

Copied

It's not the software's issue, if Wacom works and their's doesn't. Tell the company you want your money back, because their product doesn't work effectively with the number one tool for graphics production.

(Not saying you will get the refund, but they might start paying attention to making their product work.)

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 29, 2009 Jan 29, 2009

Copy link to clipboard

Copied

Unfortunately, as it's a tablet PC from HP I don't really have any leverage with N-Trig. The tablet functionality cannot really be separated from the laptop. I agree that it would be helpful if N-Trig's drivers were written in a way that were recognized by photoshop. I don't know if that would be even possible given that the two technologies are inherently different. Photoshop's tablet recognition was written for Wacom, as wacom is the most popular tablet maker and the one most used for professional design. That's why I'm not surprised that photoshop doesn't recognize this entirely different driver. I just want to get it to work.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Jan 29, 2009 Jan 29, 2009

Copy link to clipboard

Copied

Photoshop's tablet support is generic - supporting any tablet that writes to Windows standards.

You'll have to talk to HP or N-Trig about why their drivers do not work.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 29, 2009 Jun 29, 2009

Copy link to clipboard

Copied

Chris, let me start by introducing myself and my qualifications. I'm doing this to make sure you understand that I'm not a user who has a complaint - but someone who actually write commercial applications and drivers. I've been a programmer for 35 years. I've worked on products with Apple, Microsoft, Seagate, Broderbund, The Learning Company, Teradici, Madentec and many other companies. I've written software from firmware for hardware to OS components to hardware drivers to..well pretty much everything.

And yes, I've written graphics applications.

So, let me start by saying that after going through this very long, very trying thread, I have to say there's a whole lot of not-listening going on.

Let's start with one of your statements.

"Photoshop's tablet support is generic - supporting any tablet that writes to Windows standards."

Actually, as you admit later, Photoshop's tablet support is WinTab. WinTab is not 'generic' and isn't a standard component for Windows, it's a third party library created by The Logic Group that has to be licensed. Moreover,  The Windows standard for tablets isn't WinTab, it's the Ink API that was introduced for Tablet PC.

You've commented that the Ink API isn't robust or expressive enough for Adobe. You've received two different responses to that: that it's expressive enough for the vast majority of your users (which is true - the vast majority of Wacom tablets don't provide tilt, for example, so requiring it isn't really meaningful), and that they'd be happy with a partial implementation.

You've discounted this. I can see Adobe's side on this in that supporting two entirely different API for the same interfaces would be a pain - but there IS a very simple solution. I'll come back to this shortly.

You're suggesting that the 'correct' answer is for nTrig to support WinTab. There's two problems with this.

First, Microsoft is a heavy investor in nTrig and want to use their technology as the showcase for Windows 7 and multitouch. I think it's unlikely that they'll be encouraged to support WinTab. But more importantly, Ink API has changed a LOT since TabletPC came out in 2003. Even in 2005 it had been expanded to include most of what WinTab offers. The Win7 version of Ink API is a very rich API and more importantly - it IS the 'Windows standard' now and Adobe has had two years to get ready for it.

Let me repeat this: Ink API *is* the Windows standard. Not WinTab. For the simple reason that Ink ships with the OS and WinTab doesn't.

I understand your frustration with Microsoft's on again off again support for system API, but nonetheless, it has shipped since 2003 on Tablet PC systems and since 2007 with Vista and is shipping with Win7. That means it's been supported for six years. I think it's time to consider that it's going to be around for a while.

BUT...

In the end, there are two groups who can solve this: nTrig or Adobe. I would argue that regardless of 'fault', Adobe should take the intiative for two simple reasons:

- InkAPI is the future. InkAPI comes with the OS and more and more apps will support it trivially and more and more tablets and tablet PCs will avoid having to license WinTab because InkAPI is the foundation of multitouch on the PC.

- It shows commitment to the customer. We, as customers, don't care WHY we can't use Photoshop - we just know we can't. You can say 'it's the fault of the tablet maker', but that argument falls apart when we use other apps that actually DO use the Windows Ink API standard... and CAN use pressure (and multitouch for that matter). Either we're hallucinating or you're wrong. It's just that simple.

Which brings us to the simple solution:

Write a bridge module that acts like WinTab, but takes input from InkAPI. Include it with Photoshop. End of problem.

Heck, I have most of one written and at least one other company was including a similar product with their tablet. The problem we keep running into is how Adobe *uses* the WinTab library. It keeps breaking every new version. If YOU guys wrote the bridge - you could keep it in sync.

The conflict is going to be simple. A growing number of tablet computers are going to be showing up that are incompatible with Adobe products. People LIKE drawing on their screens - it's a very natural way to do it and Wacom is no longer the only source of pen technology. They aren't going to rearrange their products to support WinTab because they don't need to. Windows has its own free and standard API.

It's up to Adobe to catch up.

Oh, and one other thought... it's really bad form to swear at your customers. If you feel like swearing, you might consider taking a break and handing off the discussion to someone else for a bit while you calm down.

Cheers.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Jun 30, 2009 Jun 30, 2009

Copy link to clipboard

Copied

How nice of you to read the entire thread before commenting.

Since you did read it, you'll notice that at no point did I swear at anyone.

And because you read the entire thread, you understand that WinTab is the existing standard for tablet support:  because it is the API used by all the tablet makers (until quite recently), and is still the only available tablet API that supports anything beyond the basics, or is even extensible.  Whether that standard was created by Microsoft or some other party does not matter - not all standards are created by the OS Vendors (in fact, most are not).

And just because something ships with the OS does not make it a standard (I shouldn't have to repeat the long list of failed Microsoft API attempts here, you've been in the industry long enough to see them come and go).

The tablet support in Photoshop is generic -- there is nothing in the Photoshop code that ties it to a specific brand or model in any way.  If a tablet implements the API correctly, it works with Photoshop.  If Photoshop has a problem in the API usage, the tablet vendors (well, most of them) are good about talking to us and resolving the problem quickly.

Towards the end of the thread, you already read that we have taken the initiative and we are trying to support the Microsoft tablet API.  You also saw that we have been talking to Microsoft about the tablet API since it was created (though usually to remind them to fix bugs and that we needed improvements to make it a useful API).  Microsoft has responded to many of our requests and bug reports, but not all.  We're still not sure how much support we can provide using the Microsoft tablet API, or how much the user may have to give up if they use that API.

And you read enough to see things from Adobe's perspective:   we supported the API that everyone used; we didn't see any reason to support a new API that couldn't provide the same functionality that we already supported (even discounting the bugs); the new tablet vendors didn't want to support the standard API; and the new tablet vendors didn't contact Adobe to tell them about this lack of support (or respond to requests for contact, which I still find very odd).  Based on the information we had at the time, Adobe made all the right choices.  Now the available information has changed, and now we're responding to the change.  If someone had contacted Adobe with that additional information earlier, maybe the change could have happened sooner.

And thank you for noticing that I have been listening the entire time and trying to reach some common understanding.  Unfortunately some people posting in this thread have not been willing to consider another viewpoint, or unwilling to accept that not every problem can be fixed instantly in the exact way they wish.

P.S. Adobe's usage of Wintab is very simple, and there is no reason it should break with each version.  The interface doesn't break for most vendors, only for a few generic tablets (that get rebranded).  We notify the makers of those tablets of their driver breakage with every release (since we test their tablets along with everyone else's), and yet they rarely reply or get their code updated in a timely manner.  How they could make drivers that are specific to each version of the application is still a mystery to us.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 30, 2009 Jun 30, 2009

Copy link to clipboard

Copied

Well, I'm not here to place blame, I'm here to solve the problem as it affect me as well.

The reason I address you is that you are the only person here who can actually have a potentially positive influence in the outcome. We, as customers, cannot and as I point out in my post, nTrig and the other manufacturers of tablets who have chosen to support Ink API and not WinTab have very little motivation to do so other than to be compatible with Painter and Photoshop. I suspect they, like many of us, feel that since Ink API is free and is the actual standard for tablets promoted by Microsoft, it would make more sense for the application makers to support Ink than they supporting WinTab.

Allow me to address your points.

Before I start, I do have a question: what does Adobe do for Photoshop on the Mac? Correct me if I'm wrong, but WinTab doesn't exist there. Does that mean Adobe uses MacOS X's Ink API? The reason I ask is because the actual data provided to the application, when in packet mode, is almost identical to that provided by the Windows packets.

Apple's:

struct TabletPointRec {
   SInt32 absX; // The x-coordinate of the pointer, in tablet space (at full tablet resolution).
   SInt32 absY; // The y-coordinate of the pointer, in tablet space (at full tablet resolution).
   SInt32 absZ; // The z-coordinate of the pointer, in tablet space (at full tablet resolution).
   UInt16 buttons; // The buttons that are pressed.

                          // This integer is interpreted as a bit field, with bit 0 indicating the first button, bit 1 the second button, and so on.

                          // A value of 1 indicates that the button is down.
   UInt16 pressure; // The scaled pressure value. The pressure value is in the range 0 to 65535.
   SInt16 tiltX; // The scaled tilt x value. The tilt value is in the range -32767 to 32767
   SInt16 tiltY; // The scaled tilt y value. The tilt value is in the range -32767 to 32767
   UInt16 rotation; // The device rotation as a fixed-point value in a 10.6 format
   SInt16 tangentialPressure; // The tangential pressure on the device. This pressure is in the range -32767 to 32767
   UInt16 deviceID; // A unique system-assigned device ID. This ID matches the device ID you receive for the kEventTabletProximity event
   SInt16 vendor1; // A vendor-defined value
   SInt16 vendor2; // A vendor-defined value
   SInt16 vendor3; // A vendor-defined value
};

Microsoft's:
Microsoff's Ink system in fact, doesn't use a fixed structure, but rather uses a blind collection of propeties:

The following table is the current table of properties defines, but is infact, extensable to new features as needed:

++ NameVisual Basic 6.0 NameDefinition
STR_GUID_XXThe GUID that identifies the packet property for the x-coordinate in the tablet coordinate space. Each packet contains this property by default. The origin (0,0) of the tablet is the upper-left corner.
STR_GUID_YYThe GUID that identifies the packet property for the y-coordinate in the tablet coordinate space. Each packet contains this property by default. The origin (0,0) of the tablet is the upper-left corner.
STR_GUID_ZZThe GUID that identifies the packet property for the z-coordinate or distance of the pen tip from the tablet surface. The TabletPropertyMetricUnit enumeration type determines the unit of measurement for this property.
STR_GUID_PAKETSTATUSPacketStatusThe GUID that identifies the packet property for the current status of the cursor.

Contains one or more of the following flag values in a bit field. Use bit operators to check the status of these values.

  • IP_CURSOR_DOWN (This flag is an integer with a value of 1.) The cursor is touching the drawing surface.
  • IP_INVERTED (This flag is an integer with a value of 2.) The cursor is inverted. For example, the eraser end of the pen is pointing toward the surface.
  • IP_MARGIN (This flag is an integer with a value of 4.) Not used.
STR_GUID_TIMERTICKTimerTickThe GUID that identifies the packet property for the time the packet was generated.
STR_GUID_SERIALNUMBERSerialNumberThe GUID that identifies the packet property for identifying the packet.

This is the same value you use to retrieve the packet from the packet queue.

STR_GUID_NORMALPRESSURENormalPressureThe GUID that identifies the packet property for pressure of the pen tip perpendicular to the tablet surface.

The greater the pressure on the pen tip, the more ink that is drawn.

STR_GUID_TANGENTPRESSURETangentPressureThe GUID that identifies the packet property for pressure of the pen tip along the plane of the tablet surface.
STR_GUID_BUTTONPRESSUREButtonPressureThe GUID that identifies the packet property for the pressure on a pressure sensitive button.
STR_GUID_XTILTORIENTATIONXTiltOrientationThe GUID that identifies the packet property for the angle between the y,z-plane and the pen and y-axis plane.

Applies to a pen cursor.

The value is 0 when the pen is perpendicular to the drawing surface and is positive when the pen is to the right of perpendicular.

STR_GUID_YTILTORIENTATIONYTiltOrientationThe GUID that identifies the packet property for the angle between the x,z-plane and the pen and x-axis plane.

Applies to a pen cursor.

The value is 0 when the pen is perpendicular to the drawing surface and is positive when the pen is upward or away from the user.

STR_GUID_AZIMUTHORIENTATIONAzimuthOrientationThe GUID that identifies the packet property for the clockwise rotation of the cursor about the z-axis through a full circular range.
STR_GUID_ALTITUDEORIENTATIONAltitudeOrientationThe GUID that identifies the packet property for the angle between the axis of the pen and the surface of the tablet.

The value is 0 when the pen is parallel to the surface and 90 when the pen is perpendicular to the surface.

The values are negative when the pen is inverted.

STR_GUID_TWISTORIENTATIONTwistOrientationThe GUID that identifies the packet property for the clockwise rotation of the cursor about its own axis.
STR_GUID_PITCHROTATIONPitchRotationThe GUID that identifies the packet property that indicates whether the tip is above or below a horizontal line that is perpendicular to the writing surface.

Note: This requires a 3D digitizer.

The value is positive if the tip is above the line and negative if it is below the line. For example, if you hold the pen in front of you and write on an imaginary wall, the pitch is positive if the tip is above a line extending from you to the wall.

STR_GUID_ROLLROTATIONRollRotationThe GUID that identifies the packet property for the clockwise rotation of the pen around its own axis.

Note: This requires a 3D digitizer.
STR_GUID_YAWROTATIONYawRotationThe GUID that identifies the packet property for the angle of the pen to the left or right around the center of its horizontal axis when the pen is horizontal.

Note: This requires a 3D digitizer.

If you hold the pen in front of you and write on an imaginary wall, zero yaw indicates that the pen is perpendicular to the wall. The value is negative if the tip is to the left of perpendicular and positive if the tip is to the right of perpendicular.


Note that this is comparable to MacOS X and IS in fact extensable by defining new packet properties that are added to each point packet n very much the same way WinTab does it. Ironically, MacOS X is the most rigid of the three..

Here's WinTab's

#define PK_CONTEXT 0x0001 /* reporting context */

#define PK_STATUS 0x0002 /* status bits */

#define PK_TIME 0x0004 /* time stamp */

#define PK_CHANGED 0x0008 /* change bit vector */

#define PK_SERIAL_NUMBER 0x0010 /* packet serial number */

#define PK_CURSOR 0x0020 /* reporting cursor */

#define PK_BUTTONS 0x0040 /* button information */

#define PK_X 0x0080 /* x axis */

#define PK_Y 0x0100 /* y axis */

#define PK_Z 0x0200 /* z axis */

#define PK_NORMAL_PRESSURE 0x0400 /* normal or tip pressure */

#define PK_TANGENT_PRESSURE 0x0800 /* tangential or barrel pressure */

#define PK_ORIENTATION 0x1000 /* orientation info: tilts */

#define PK_ROTATION 0x2000 /* rotation info; 1.1 *

Each of these identify a packet property structure which contain more details. For example: PK_ROTATION marks a tagRotation object

struct tagROTATION { /* 1.1 */

int roPitch;

int roRoll;

int roYaw;

)

which provides for 3D rotation.

There are additional parameters for sliders, rings and buttons, but these are usually handled through the messaging system in Windows, not through the InkAPI as they're considered HID, not Pen.

However, this leads to a relevent question. Precisely *what* features are you anticipating being added in the forseeable future that cannot be handled with either of these data sets? You've got 3D position, 3D rotation, 3D tilt,  normal pressure, tangental pressure, and even button pressure. And contrary to what you've said several times, the Microsoft PacketProperty is in fact extensable by simply including a new ID and adding the property object to the PacketProperty collection for the sample.

Really, if you have plans for a new version of Photoshop that honestly needs more than that - I really would love to hear about it - not to mention see the tablet you'd need to make it work. Currently NO Wacom tablet support all the features that are there NOW.

On to standards.

Actually, in general, it depends on who is driving the market. For example, SQL is a standard, yet Oracle, Microsoft and SAP all implement it differently. However, the #1 most commonly used database isn't any of them. It's Access, which gets its SQL interfaces via ODBC. Which is Microsoft's definition. It won because Access support is delivered with the OS through ODBC which is included with the OS, and it provided a consistent way to access DBs.

In the digital paint/touchup market, Photoshop is the 800lb gorilla and until now has been able to dictate what people do to work with it. (Consider the huge market for PS plugins...). Thus, when YOU say 'use WinTab', you are defining the standard for Photoshop. The problem is, Microsoft is defining the standard for tablets outside of Photoshop. So, it comes down to a bet: who's going to be right? Microsoft or Adobe? Normally, I'd bet on Adobe, but I'll be honest, this time I think it's MSFT. Touch screens are the future. Even netbooks are getting them.

Yes, there have been API that come and go - this is true for Apple as well - remember OpenDoc and QuickDraw 3D and GX? However, as I noted, Tablet PC and the Ink API showed up in 2003 and is still here. It's a part of Win7. At least for client versions of Windows, it doesn't seem to be going away soon - and with the new resurgance of interest in touch screens (thanks in part to Apple and the iPhone), I think it's safe to say it's not going away. I guess my comment would be that it would have been prudent to stick someone on just keeping on top of Ink API and be ready to support it if it became dominant.

Here, to me, is the best reason to dump WinTab in the future though. This is quoted from Telegraphic's page on WinTab, which used to be a technical support page:

Wintab Information
In 1999 an inventor sued our company claiming that the functionality of the Wintab API was covered by a patent the inventor was granted in 1998. One of our customers became involved in the litigation, and on October 16th 2001 the Federal District Court hearing the case ruled in our favor on several motions for summary judgment, finding non-infringement of claims 1-10, and invalidating the remaining claims 11-14 based on prior art.

Subsequently the inventor appealed the rulings on claims 1-10 and 13-14 and the Court of Appeals for the Federal Circuit vacated the lower court's decision and sent the case back for further hearings in 2002.
Appeals Court Ruling

The litigation continued to grow, with a new lawsuit regarding another patent being added to the mix. Ultimately in 2004 we settled the litigation with the inventor and his company.

Pursuant to the terms of the settlement we are no longer offering licenses to our implementation of the Wintab API for digitizing tablets.

The beauty of using Microsoft's Ink API is that they're not likely to sue for your using it. Also, it supports ActiveX/COM and Managed (,Net) interfaces, making it insanely easy to use.

I did read your comment that Adobe is planning on supporting Ink API in the future and I applaud this. However, I don't mean to seem overly critical, but without a sense of when it will happen (especially in context of some of your comments in this reply), it sounds like Adobe has been thinking of supporting it for quite some time and yet, still doesn't. Some sense of a timeframe would do much to give us some comfort. I appreciate you can't give a commitment - but even something like 'we hope to have it for CS8, but can't promise' would be a huge help.

I guess the thought to take away from this is that Photoshop is the de facto standard and when Tablet PCs made by the two largest computer companies: Dell and HP, don't work with it, we get nervous. The Dell Latititude XT,. for example, was a $2500 laptop. The HP tx2z is around $1400. Compared to say a $80 Graphire, that's significant cash and when it doesn't work with $799+ Photoshop, but does work well with a $29 app like ArtRage, we go 'what the???' When the best suggestion we can get for fixing this is 'go back to nTrig'... well, be honest here - how often has that really worked?

The WinTab compatibility issue comes directly from experiences with various non-WinTab tablets like the Aiptek ones which used an Ink-to-WinTab bridge in the form of a replacement DLL for WinTab. Most of them found that going between CS2 and CS3, the bridge broke and they had a hard time getting it working again. I'm not privy to the details, so I can't offer you more than that, I'm afraid, but it's telling that all of the bridge solutions I've seen - most of which were *specifically* written to support Photoshop - are gone now.

One last comment, it's been pointed out that I may have confused the source of the swearing - towards the end of the thread things were getting rather confused and everyone seemed quite upset, If I've misattibuted that to you, please accept my apologies.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Jul 01, 2009 Jul 01, 2009

Copy link to clipboard

Copied

"Ink" on MacOS is very different from "Ink" on Windows (or the other APIs/features known as "Ink" over the years).

And that structure you documented looks more like the MacOS Classic Wacom interface - not at all like the current MacOS tablet event interface.

Yes, some of the data is similar between MacOS tablet events and Windows tablet APIs - that's to be expected.   But the event handling is different.  On MacOS, we had to work with Apple for quite some time to get acceptable tablet event tracking via low-level APIs (there are lots of issues that OS vendors don't think about when creating these APIs).  We don't yet know what it will take to get acceptable quality from the Microsoft tablet API.

I can't commit to timeframes for new versions:  there are laws and corporate rules that prevent that.  I wouldn't commit to a timeframe even if allowed - because we don't know how many problems remain in the Microsoft tablet API.   We're trying to make it work, but not sure yet how long it will take to make it work.  If we have to wait for Microsoft to fix critical bugs, it might be a while.  We just don't know.

Of course, anything we know about future plans for third party devices would be covered by an NDA (or more likely: a dozen different NDAs).

Most honest(*) hardware makers have been good about communicating with software vendors, working with them to resolve problems and fix bugs in their drivers.   This is one of the few times I've seen a hardware vendor completely blow off their customers and fail to communicate with software vendors.  This really would have been trivial for the tablet companies to fix.  Even if they had talked to Adobe about the problems we could have worked something out a lot sooner.  But I can't believe they shipped without support for major applications, knew that they weren't supporting the common API, and then blamed applications for the missing functionality in their own drivers.  I can understand how customers who purchased systems using those tablet technologies are frustrated.  We are just as frustrated to learn about this after the fact, and by the continued lack of communication from those tablet companies.  Being blamed for something well within the control of the tablet companies, but that we knew nothing about -- that just makes it worse.

(*) There have been bad eggs, but they never stay in business long.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 02, 2009 Jul 02, 2009

Copy link to clipboard

Copied

I apologize for joining this conversation late, but I have just recently purchased a Dell XT2 for my wife, who is an artist and a designer. I am a web developer, so if nothing else, we figured we'd both get a lot of use out of the device. She makes use of the now (quasi-)defunct Wacom Graphire, and we've been looking to find a portable solution that worked pretty well.

Long background story made short: we had no idea that the APIs for these particular pieces of hardware were so complex as to not provide pressure information to certain applications.

I've searched through the forums and not found an answer to this question or if it was asked, but if it was already, I again apologize... but certain applications (the example that comes to mind is ArtRage 2) have support for both the N-Trig based API and the WinTab API. Are there factors of which we are not aware as consumers that would prevent Photoshop from providing the same support?

Personally, I don't think demanding instant adoption of multi-touch and other features that are exclusive to N-Trig is very fair or realistic, but I think it's fair to expect at least pressure sensitivity to be provided for this fairly popular software. Again, I apologize if I come across as demanding or with a sense of entitlement, and I don't expect a deadline or delivery date for this functionality... but can we expect as of this post (July 1st, 2009) Adobe is actively working on support for this hardware, so there's no reason for me to throw in the towel and return this hardware before the return policy tops out?

I thank you for fielding questions and being active in the customer area, and am looking forward to hearing more news about this release.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 03, 2009 Jul 03, 2009

Copy link to clipboard

Copied

"Long background story made short: we had no idea that the APIs for these particular pieces of hardware were so complex as to not provide pressure information to certain applications."

That's not precisely correct. It's not a question of complexity - and all of them provide multiple kinds of pressure. The actual problem is fairly simple: until recently Wacom, which is the major maker of art oriented digitisers, used and supported WinTab, a proprietary library for tablet support. Many, if not most of the other professional grade tablet makers did too because there was no support for it in the operating system. This is the software that Adobe uses to interact with said tablets.

However, since 2003, MacOS X added Ink and Windows added Tablet PC - both of which included similar functionality. However, since the Tablet PC subsystem only shipped with Tablet PCs, it really could not be considered a reliable component of Windows. When Vista shipped, all versions above Home Basic included the Tablet PC components, which meant for the first time, there was a standard API for tablets in Windows that was included in most of the shipping copies of Windows. It's been extended and improved and now supports multitouch and gestures as of Windows 7

This Tablet PC subsystem is independent of WinTab, and there's no connection between the two, so if you write software that uses WinTab (like Photoshop and Painter) and have a tablet that uses Tablet PC Ink (like the N-Trig and Aiptek tablets), they won't work well with each other. Specifically, no pressure information.

As for how hard it would be to make them work together... well, that depends entirely on how the software using it is written.

I've suggested using a bridge that translated from Tablet PC to WinTab, but because that's proprietary and because the company who owns WinTab has been suing people who try to duplicate its functionally, it's probably not worth the risk.

I don't think anyone on this forum expects Adobe to support gestures or multitouch. Photoshop isn't really well suited to those. Like you, we just want pressure sensitivity on the pen and eraser ends.

I mentioned multitouch simply to show that Microsoft is unlikely to dump support for NTrig or touch/pen screens anytime soon.

Cheers.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 02, 2009 Jul 02, 2009

Copy link to clipboard

Copied

Hi, I'm new to all of this, but I've been reading this thread and a few others.

I recently bought an N-Trig-based Tablet PC, and was surprised and disappointed to find out about these compatability issues.  I've decided to keep it anyway, as there are several other factors that make it worth keeping, but on to my point:

I was reading about Theo's work and research on a bridge between the Ink and Wintab drivers, and I was trying to think of different ways to implement that (I have some programming experience, but mine is geared more towards web languages and such, not hardware).  What about creating a virtual device, IE, a virtual tablet, that would use the wintab driver but get its input from the ink driver?  I've seen virtual devices done before with programs like Hamachi's virtual network adapter, or MagicISO's virtual CD/DVD drives.

So what about writing up a virtual wacom tablet?  The OS would believe that it's hardware just like the above examples (or so I assume), so when you try to install the wintab driver, and it looks for compatible hardware, it finds the fake.  The virtual tablet would get all of its input data from the Ink driver, but format it in such a way that Wintab could understand it.  Would something like that work?

If I had the foggiest idea of how to go about creating virtual hardware and interacting with drivers at the programming level and so on, I'd give it a try myself.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jul 02, 2009 Jul 02, 2009

Copy link to clipboard

Copied

ARrr! That's the spirit, matey!

I fielded similar questions to some bit-head friends of mine--no luck yet.  I love Wacom (own an Intuous, Graphire, and bought a Bamboo for a friend) so, I feel dirty supporting the notion that it's good to get that "Wacom Feeling" for less.  But at the same time, after I first posted to this forum I read up in the forums about all the kiddos in their basements making drawings in Microsoft Ink applications, and my heart melted.  There's got to be a way to make this lower cost hardware play well with others.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 02, 2009 Jul 02, 2009

Copy link to clipboard

Copied

Wacom for less? Lower-cost hardware? I paid 2,400 dollars for this machine dude. WTF are you trippin on?

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 03, 2009 Jul 03, 2009

Copy link to clipboard

Copied

That's essentially what I mean by a bridge.

You'd write a WinTab driver that doesn't talk to real hardware, but talks to the Tablet PC Ink and Windows Messaging and translates it to WinTab compatible results.

Alternatively - you'd write a whole new WinTab DLL that presents the right API to Photoshop, but translates it to the appropriate Tablet PC calls.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

I found this the other day:

http://www.touchsmartcommunity.com/forum/thread/423/TouchSmart-tx2-1020-with-Photoshop-Corel-ARRRGH-PLEASE-HELP/?page=11

Scroll about halfway down.

Apparently Synaptics has released a version of wintab.dll that works, but only if you're using Linux.  Any chance of porting that to windows?  I'd rather not have to run Photoshop inside of Wine inside of Linux which is installed inside of Vista. =P

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

So, possible solutions people have suggested:

1. Create an API wrapper for the Windows API

2. Try to port over a Linux library file to Windows

3. Emulate windows in Linux in Windows.

I asked a friend if he or any of his cohort in the computer science doctoral program could make the N-trig favored Windows API masquerade as or misinform WinTab so as to mimic using a WinTab loving device... but the reply was something along the lines of "Deeeeerrrrr... we like algorithms.  Can I pet the rabbit, George?"  Then, the secondary response from a friend in the Industry was "Everybody who knows Windows already has a job and thanks to downsizing I'm doing two people's work right now,  Sorry."  So the problem seems to be pointing a capable person towards our shared problem.

Where do we find the people to point towards this issue?  It's not just a patch to make Photoshop pay attention, it's all the other programs, like Embird the embroidery digitizer and Painter X and the hoard of other suddenly Legacy WinTab programs.

And where's the legality of it all? The murky past leading to the arugeably illegitimate current ownership of WinTab makes me wonder if hiring the first goon/genius I can find would lead to infringement charges.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

For me - the biggest issue is the legal one.

Logic Group has already threatened people who have tried to make their own WinTab clones. Personally, I think they'd lose the legal battle because there's tons of precedent to show that an API is considered a 'language' under copyright law, and thus isn't protected, so they'd have to show that implementing an equivalent technology would violate a patent - and there's nothing there I can see that could be patented.

But I'm not a patent lawyer, and since I'd be giving this away, I couldn't afford the legal costs if I'm wrong.

This is why it really comes down to either nTrig licensing WinTab, or Adobe supporting Ink. And it's why I think supporting Ink is the better solution because in general, if you have a choice between proprietary and legally protected solution, or a more open solution, the more open solution is the better choice.

(and yes, I just suggested that a Microsoft product is the more open of the two ... that alone should speak volumes...

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied


Well there is a WinTab API wrapper out there, it's called VBTablet, http://sourceforge.net/projects/vbtablet/. I was able to get it to load, but only because I had a copy of the wintab32.dll that came with my wife's previous Wacom Tablet (the graphire) and it detects the motion and information from the tablet as well as displaying that information through scripts, as I've tested a few. The trick is: someone needs to be comfortable enough with the Windows Tablet API that they can route the input that's being measured from it into a meangingful set of inputs to the "virtual device" you've set up using this wrapper into the application, and/or vice versa.

I'm not terribly comfortable with OS programming, but I've been able to hack around a bit with it. I'm just curious how much legal action I could be facing if I continue, and I hesitated to post this wrapper here, but it's on sourceforge already so it's not like someone hasn't already seen it.

Not sure if that helps at all, but I'd be willing to work on it with someone if they knew more about it.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

That wouldn't help really - it's a wrapper around the dll so VB programmers can use the DLL in VB.

I've found the Wine source for their WinTab.dll replacement which apparently supports nTrig, and I think I'll take a shot at getting it to compile in Windows directly. Then we can just replace the WinTab that ships with Photoshop and voila. Problem solved.

If Wacom or LogicGroup want to sue me - I'll just point them back to the Wine project and redirect them.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guru ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

Your posting a hacked version thus you changed something. I think you answered your own question. Just don't take a chance by posting something your not sure of. I understand what your trying to accomplish but like you said is it worth the legal action?  

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

Well, honestly, N-Trig supporting WinTab would be much more preferable, due to the fact that it would allow all applications that use WinTab to work on N-Trig Hardware. But I would assume that due to Microsofts 25 million dollar investment in N-Trig, part of that is a non-comp agreement that entails only supporting InkAPI. Since that isn't happening, it's preferable for Adobe to support both APIs. Preferable to nothing. Photoshop is the most cared about digital imaging workstation, however after Photoshop incorporates Microsoft's API as best they can, as they said they are in the precess of doing right now, I can only assume the forums of the other popular digital imaging workstations will look just like this one. Baby steps I guess. Although most of us have been a pain in Chris Cox's and Adobe's ass in this thread, it should be somewhat flattering that we chose to be a pain in your asses first.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

I'm afraid I have to disagree with you, for reasons I've already stated.

Ink is the official API for tablets and other similar devices provided by Microsoft for Windows. As of Vista, it ships with every consumer/workstation version of Windows, and it's been available for at least four years before that. It's well documented and well supported. It, in conjunction with the other API in Windows for things like buttons, can support anything Wintab can and is extensible. It's free and there are no legal ramifications for using it either as an application developer or as a driver writer. It's directly supported both in raw WinAPI and in .Net. It's supported by a growing number of tablet maker who have chosen not to support Wintab (which is mostly an issue because of Wacom). A growing number of apps are supporting Ink API and either are also supporting Wintab, or are not bothering to support it because even Wacom supports Ink API. Ink API is the foundation for all future UI improvements not just for tablets but for multitouch and Surface. Photoshop may not use this feature, but other apps will - which means they'll support Ink API before Wintab.

Wintab may have been the defacto standard for applications, but that doesn't make it a better one, nor does it mean that it has to be the only one supported.

Now, the rest of your comments leave me confused. Photoshop is an application, not a platform. It's just one app of many that you can run on your computer. It actually has competition - like Painter for example. Photoshop is definitely the leader in its market (for now), but I think you may be overstating its importance just a bit. There are LOTS of other apps that support pen input and touch that support Ink including ArtRage. Ironically, it's the two big names in photo/painting that don't: Painter and Photoshop.

I'm sure Microsoft's investment in N-Trig does indeed play a part in the reason there's no WinTab for the N-Trig technology - BUT - there are a growing number of tablet makers who have nothing to do with Microsoft who also are skipping over WinTab... because it's not needed for most things.

Finally, I don't consider these comments a pain in the ***. I'm looking for a solution. I just don't believe playing the pass-the-buck card is particularly productive. As a commercial application developer, when someone comes to me with a legitimate issue, I don't say 'go to talk to the other person', I try to solve the problem and if that means my talking to the other person and trying to arrange something that works, I do.

It comes down to this: N-Trig has no need to support Photoshop by making a Wintab driver when it works out of the box with so many other applications and when their big focus is system UI. Photoshop users are a tiny subset of the market they're going after. On the other hand, if NTrig's technology (and the other similar technologies like the ones used by Aiptek in their tablets) becomes popular and widespread, Adobe will find themselves more and more often being accused of falling behind if they don't support Ink because the people buying the computers and tablets don't want to hear it. They just want it to work.

And people like myself, who could fix the problem by writing our own bridge replacement for WinTab, do so at huge legal risk because Wintab is proprietary and the company that owns it - LogicGroup - has made it clear that they will sue.

So in the end, the only solution that fixes EVERYTHING is for Adobe to support Ink. And Chris has indicated that Adobe is indeed working on it. To me, we're on the road to a solution.

I don't see what the problem is other than we don't know how long we have to wait.

So feel free to be as big a pain in the *** as you wish. Doesn't bother me. I have nothing to gain or lose by it.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

agree to disagree haha.

N-Trig Supporting InkAPI and WinTab = All programs supporting both API's

compatible with N-Trig Hardware.

Adobe Supporting WinTab and InkAPI = Photoshop works with N-Trig Harware.

As an N-Trig hardware owner, I'm going to have to find the first out come

slightly more preferable.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Jul 05, 2009 Jul 05, 2009

Copy link to clipboard

Copied

it should be somewhat flattering that we chose to be a pain in your ***** first.

Not quite ROFL, but I fell out of my chair laughing at that.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jul 04, 2009 Jul 04, 2009

Copy link to clipboard

Copied

Wow... now THAT is a complicated solution to a simple problem.

Still, you're right - if they have a WinTab.dll that works in Wine, it should work just fine in normal Windows since Wine is just a port of WinAPI...

I'll have to look into this...

Maybe I can repackage it so you don't need the rest of the stuff.

No promises though.

Likes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

Save time with Adobe Express quick actions